Andrea Arcangeli wrote:
>
> > o wake_one semantics for accept() (Andrew Morton)
>
> I dislike the implementation. I stick with my faster and nicer implementation
> that was just included in aa kernels for some time (2.2.18aa2 included it for
> example). Andrew, I guess you didn't noticed I just implemented the wakeone for
> accept. (I just ported it on top of 2.2.19pre2 after backing out the wakeone in
> pre2)
Yes, I noticed your implementation a few weeks back.
'fraid I never liked the use of the TASK_EXCLUSIVE bit in
task_struct.state. It's an enumerated state, not an aggregation
of flags. Most of the kernel treats it as an enumerated state
and so will happily clear the TASK_EXCLUSIVE bit without masking it
off. Fragile.
If a task is on two waitqueues at the same time it becomes a bug:
if the outer waitqueue is non-exclusive and the inner is exclusive,
the task suddenly becomes exclusive on the outer one and converts
it from wake-all to wake-some!
Is it faster? Not sure. You've saved a cacheline read in __wake_up
(which was in fact a preload, if you look at what comes later) at the
cost of having to mask out the bit in current->state every time
we schedule().
Anyway, it's academic. davem would prefer that we do it properly
and move the `exclusive' flag into the waitqueue head to avoid the
task-on-two-waitqueues problem, as was done in 2.4. I think he's
right. Do you?
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 23 2000 - 21:00:26 EST