> From: Arnaldo Carvalho de Melo [mailto:[email protected]]
>
> > > And I don't really want to review a 176 KB patch (although I did
already
> > > look over most of it a few days ago). Do people want to take portions
> > > of it for review and then see about Alan merging it, e.g.?
As long as they use set_current_state() and not the __ counterpart,
then they are ok [the memory barrier being to blame for the lost
performance if any is found].
> > Hmm. Has anyone considered a "Kernel Janitor's" tree? More
specifically,
> > a patch set, much like -ac or -mm, with the current cleanups so they
> > can be tested, pulled, run through automated batch testing, etc.?
>
> That is an interesting idea, I'll probably start one.
That's very interesting.
I?aky P?rez-Gonz?lez -- Not speaking for Intel -- all opinions are my own
(and my fault)
>
>> From: Arnaldo Carvalho de Melo [mailto:[email protected]]
>>
>> > > And I don't really want to review a 176 KB patch (although I did
> already
>> > > look over most of it a few days ago). Do people want to take portions
>> of it for review and then see about Alan merging it, e.g.?
>
> As long as they use set_current_state() and not the __ counterpart, then
> they are ok [the memory barrier being to blame for the lost
> performance if any is found].
Yes, last week at least the patch did use set_current_state() almost
exclusively, even when it didn't need to -- most likely.
>> > Hmm. Has anyone considered a "Kernel Janitor's" tree? More
> specifically,
>> > a patch set, much like -ac or -mm, with the current cleanups so they can
>> be tested, pulled, run through automated batch testing, etc.?
>>
>> That is an interesting idea, I'll probably start one.
Yay!
Thanks, acme.
~Randy