> >wake-one alone solves the problem, doesnt it? And we have wake-one in
> >2.3.3. I'm curious how that patch looks like nevertheless. (i'm just
> >rather convinced that it cannot be done constant-time without giving up
> >crucial scheduling features, but i'd be happy to be proved otherwise.
> >There _are_ ways to make it constant, it just sacrifices things like
> >proper SMP scheduling.)
>
> It doesn't completely. The current wake-one only works if the process
> blocks in accept, which means only a single listen socket, which means only
> a single virtual web server. Fortunately most web benchmarks only test that ;)
>
> For the processes not lucky enough to only require a single
> socket/file/whatever there is currently no way to get wake-one semantics
> over poll/select. All processes polling have to be woken up, although only
> one will finally accept.
yes. Wake-one functionality has to be added piece by piece, accept() being
the most obvious example. Some other candidates: SysV semaphores, flock(),
maybe even pipes/fifos. The point is that the basic infrastructure has
been added in 2.3 (doubly-linked and cleaned up waitqueues, TASK_EXCLUSIVE
and an example user of the infrastructure: accept()), so the rest can be
added incrementally.
-- mingo
-
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/