True, but neverthless 3 ms is enough time to suck in 150 kBytes of
data into cache (assuming 50 MBytes/sec bus). And each thread should
be executing *nearly* the same code as the others.
> > It only needs to be done "right" once. In a library. Heck, I might
> > even modify my own FD management library code to do this just to prove
> > the point. Write once, use many!
> > Note that even the "complex" migration is optional: simply dividing up
> > FDs equally between N threads is a win.
> > Having migration between a small number of threads is going to be a
> > *real* win.
>
> Right, and if you'll release this in a license other than GPL (i.e. LGPL
> or MPL) so that it can be reused in non-GPL code (i.e. NSPR which is NPL),
> that would be most excellent. (acronyms rewl).
Err, well, I didn't mention a license, but as it happens my library is
LGPL.
> > This involves kernel bloat. It seems to me that there is such a simple
> > userspace solution, so why bother hacking the kernel?
>
> I don't think the userspace solution is as fast as the event queue
> solution.
Actually, I probably agree. But for me it's not the point: I believe
we can provide a sufficiently fast, scalable and lightweight
implementation in userspace, such that I/O completion ports and other
(kernel-space) features are not required.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu