Messages in this thread | | | From | (Alan Cox) | Subject | Re: Overscheduling DOES happen with high web server load. | Date | Fri, 7 May 1999 01:26:34 +0100 (BST) |
| |
> Do these play patches implement it the way Linus has suggested to us? > > He makes a lot of sense, because in the cases I have studied he is > right, only the task going to sleep has the correct knowledge about > whether wake-one semantics can work or not.
For my playing they dont. I can demonstrate that for a listening socket the worst case is we take a wake of all for some weird cases. At least to my satisfaction, and providing I ignore select on listening for testing cases. I broke select and have an if(port==80) type check for wake one - its ugly OK ...
Linus theory btw doesnt work either.
> [ for everyone else's benefit Linus's suggestion is for the task to > indicate, when placing himself on the run queue, that he is > "wake one" capable, then the wake up routines stop doing work > when they hit the first task which is marked this way and is not > running already ]
Unfortunately you also need to consider a common case where another task POSIXly requires waking. The classic is select(). Such tasks should always be woken.
You need to be a bit smarter thats all. wake_one must wake the first sleeping (that is important - a task on the wait queue already running being woken alone raises all sorts of funky races) wake_one mode task and anyone who is 'wake my always'.
Not much more complex. With a very scalable system it would be good to keep a count of tasks in wake all to avoid an O(n) list walk for the non select cases.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |