Re: [PATCH 1/3] wait-simple: Introduce the simple waitqueue implementation

From: Paul Gortmaker
Date: Thu Dec 12 2013 - 09:48:29 EST


On 13-12-12 05:56 AM, Thomas Gleixner wrote:
> On Thu, 12 Dec 2013, Christoph Hellwig wrote:
>
>> On Wed, Dec 11, 2013 at 08:06:37PM -0500, Paul Gortmaker wrote:
>>> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>>>
>>> The wait_queue is a swiss army knife and in most of the cases the
>>> full complexity is not needed. Here we provide a slim version, as
>>> it lowers memory consumption and runtime overhead.
>>
>> Might it make more sense to just make the simple one the default and use
>> the complex one in the few cases that need it?
>
> Sure.

The one major downside of doing it that way, is that it becomes
a flag day event instead of a gradual roll out. Any unexpected
fallout will bisect to the one commit, which kind of would suck,
if we happen to trigger something kooky like the 50w mwait issue,
or break the usb stack somehow.

If we do the flag day type change, where complex wait is what we
have currently, and simple wait is the default, then I guess the
logistics would be something like:

1) git mv wait.[ch] --- > cwait.[ch]
make an empty wait.h include cwait.h temporarily

2) rename all existing functions in cwait.[ch] to have an added
"c" prefix (or similar)

in wait.h, temporarily add a bunch of things like
#define wait_xyz cwait_xyz
so that things still compile and link.

3) track down the users who really need the extra complexity
and have them use cwait calls and include cwait.h

4) bring in the simple wait queue support as wait.c and wait.h
and delete the defines added in step two. This will be the
flag day commit.

Is that what we want to do here?

Paul.
--

>
>> It would also be good to enumerate those cases. The wake callbacks come
>> to mind, but I guess there are more?
>
> You can convert everything which uses default_wake_function and does
> not use the exclusive wait trickery.
>
> Thanks,
>
> tglx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/