Messages in this thread |  | | Date | Thu, 12 Dec 2013 09:48:06 -0500 | From | Paul Gortmaker <> | Subject | Re: [PATCH 1/3] wait-simple: Introduce the simple waitqueue implementation |
| |
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@linutronix.de> >>> >>> 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 >
|  |