Re: mmap() versus read()

David Wragg (dpw@doc.ic.ac.uk)
Thu, 12 Mar 1998 16:59:02 GMT

Perry Harrington writes:
> [snip]
>
> If you implement threads in userspace, signals is a REALLY BAD way of
> doing context switches. Is it possible for an LWP to register a routine
> to be called on a OS context switch? Each process has a quantum of 200ms
> (according to sources on the list), slicing this 200ms accross LWPs
> (clone() threads) and letting each thread know when a context switch has
> ocurred would make userspace context switching trivial. So, instead of
> using signals and timers, is there an asynchronous way of letting an LWP
> know when it has continued from a context switch? Say, every 5th context
> switch, we schedule a different thread...moving the last thread to the
> bottom of the queue, this would also allow for a pthread_yield() to work
> more efficiently.

I haven't seen this mechanism in any Unixoid OS. But then, it would be
a rather obscure feature, so I wouldn't actually expect to hear about
it for any OS that I haven't read up on in depth.

I don't think that it is using signals to do user-space context
switching that is a bad thing, but using signals resulting from
setitimer() (i.e. SIGVTALRM (sp?)) may be.

As it happens, I implemented this in Linux a few weeks ago. A process
uses a new system call to nominate a signal that gets delivered at the
start of each quantum. Since the signal gets delivered when exiting
from the kernel into the process, and the only additional cost is the
sigreturn syscall after the signal handler has fiddled about doing
whatever user-level context switches it wants, this scheme _should_ be
cheap (relative to the kernel context switch it is tagged on the end
of). It seems solid, but what I haven't got around to doing yet is
testing it to see if it does actually result in any significant
saving, and how it works out in practice. If it looks good, then I was
going to see if there was any chance of getting this in the kernel.

My concerns are not over the cheapness/expense but over whether this
is a userful mechanism. You suggest having a user-space quantum
lasting 5 kernel quanta, but that would seem to be 1 second! In fact,
since user-space context switches are cheaper than kernel
context-switches, you probably want more than one user-space quanta to
occupy each kernel one. Even in this case, it doesn't necessarily mean
the "signal-on-switch" idea is a bad one; doing the first switch at
the start of the kernel quantum, and then additional switches by
setitimer() may be a win. This is one of the things I intend to find
out. If the worst comes to the worst, I should find out that the
cost of itimer-based user-space context switches is cheap enough that
it isn't worth worrying about.

As for sched_yield(), I don't much care about that. Apart from
implementing thread libraries (and even then you only need it in one
place where its performance isn't critical) I can't see a good reason
to use it.

--
Dave Wragg


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu