Wouldn't this entirely hose up userspace alarms??? Wouldn't you have to
emulate the userspace alarm functions?
>
> 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,
I was under the assumption that thread scheduling took a fraction of the
actual process quantum. Meaning that threads didn't get a full 200ms quantum.
Is this wrong?
> 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.
I'd be interested in the outcome of your testing.
>
> 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.
I'm referring to a userspace pthread_yield, when that's called, the thread
voluntarily puts itself at the end of the queue, perhaps before it's
quantum is up. This means that scheduling would be asynchronous, because you
would just want to waste the rest of your quantum (or would you want to
give it up?) The assumptions I was making was that the quantum for threads
would be significantly shorter than the quantum for the "process" (200ms),
this would make userspace context switches very easy to implement, hence
low overhead.
>
> Dave Wragg
>
--Perry
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu