svn commit: r333266 - head/sys/amd64/amd64

[Juli Mallett]

On 4 May 2018 at 16:12, Mateusz Guzik <mjguzik at gmail.com> wrote:

> On Sat, May 5, 2018 at 12:58 AM, Steven Hartland <
> steven.hartland at multiplay.co.uk> wrote:
>
>> Can we get the why in commit messages please?
>>
>> This sort of message doesnt provide anything more that can be obtained
>> from reading the diff, which just leaves us wondering why?
>>
>> I’m sure there is a good reason, but without confirmation we’re just left
>> guessing. The knock on to this is if some assumption that caused the why
>> changes, anyone looking at this will not be able to make an informed
>> descision that that was the case.
>>
>>
> bcopy is an equivalent of memmove, i.e. it accepts overlapping buffers.
> But if we know for a fact they don't overlap (like here), doing this over
> memcpy (which does not accept such buffers) only puts avoidable
> constraints on the optimizer.
>
> This is a rather pedestrian change which can be made in many places,
> I don't see the point of repeating the explanation in each one. Although
> I guess it would make sense to point at a specific commit which explains
> things.
>

I feel like the second paragraph in particular suggests a methodical
project (maybe in a branch?) to convert or mark all instances as
not-to-be-converted based on their context and practical concerns (like
performance) might be better than doing a bunch of one-off commits, with
batched commits to -CURRENT from time-to-time.  Then it's easy to say
"Phase IV of bcopy analysis in kernel: convert to memcpy for all
non-overlapping small copies" with a whole bunch of changes lumped together.