[lkml]   [2000]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.2.19pre2
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.772 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site