The question: Is user-level context switching is ever a good idea? At
one extreme are applications that use lots of Unix semantics in their
threads.
At the other extreme are applications that want very light weight
threads, and hardly interact with Unix at all -- though they must be
securely contained by it. And they must share with other Unix users
etc. even though they don't communicate much with them.
These are applications that have a lot of worker threads doing
calculations or other things the kernel hardly ever sees, and want to
communicate between threads efficiently. But occasionally a thread
wants to call the kernel (say to log a message, get a timer tick etc.),
so Unix thread semantics are required.
I claim that certain specialised light weight threads can context switch
a lot faster in user space than kernel space -- not least because they
don't have to switch a whole context.
It follows that there just _might_ be a way to combine this with Unix
thread semantics to get the best of all worlds.
> OK, so this is a single user device, right? If the kernel isn't
> arbitrating access to the device then you either have to have a bunch
> of friendly (and smart) users or it's single user. Once again, hardly
> a fair comparison. You can make just about anything have really great
> performance if you drop off all support for time sharing, etc.
The system time shares at the same time -- it's just this app has
exclusive access to the device. Other users can use the machine
(crapping on performance but that's tough luck).
Basic Linux semantics are retained, and all this busy threading &
communication is nicely contained within a single group of Linux
threads.
> Great, go ahead. What are the AF_PACKET numbers doing the same thing?
Darn, where'd I put them... :-)
Numbers have been quoted at me before. I'll see if I can get hold of them.
> Err, the only numbers you have quoted are for TCP/IP and your raw packets.
> You haven't quoted the kernel raw ethernet + demultiplexing numbers
> anywhere that I've seen. Or did I miss that?
No you didn't miss it -- I've heard the numbers but don't remember --
but they weren't good. Mind you most of the overhead goes in the
kernel<->user packet copying and handling interrupts -- these Intel
boxes just don't do fast interrupts.
> Anyway, if your hardware can get these numbers without kernel support,
> I'm pretty sure you can also get these numbers with kernel support.
I agree. That's my point of view. I'd like to take his neat tricks and
somehow make the kernel just as quick while preserving Unix semantics.
- You may have noticed me mention polling in network drivers a while back.
- There's sysenter/sysexit which might help, I'm not sure.
- Losing the kernel<->user copy is significant, if you don't care about
checksums or the hardware will do it. I base this on extrapolating from
experiments with the user-space driver. Doing this efficiently
within the standard API is a challenge :-)
- One of the things that may make kernel threads quicker is perhaps to
optimise context switching further -- by cooperation with user space.
E.g. there is no need to save/restore FPU context even when the FPU is
used, if you can do the context switch at a function boundary. And so
on.
The last point is why I'm involved in this discussion.
-- Jamie
-
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/