:
:I was rather suprised when I found out just how expensive kernel entry was
:some time ago.. What I was doing was a reentrant syscall that aquired no
:locks and ran about 5 instructions in kernel context.. Anyway, it took
:something like 300 times longer to do that (called via int $0x81) than to
:do a 'call' to equivalent code in userland. Anyway, with overheads on that
:scale, whether we push 5 or 8 or whatever registers in the handler is
:almost lost in the noise.
:
:Cheers,
:-Peter
Well, it could be 300x but that's like comparing a cache hit to a cache
miss - in real terms a UP syscall takes, what, 1-3 uS? An SMP syscall
takes 6 uS. This on a PIII-450. Both times can be cut down to less
then 500nS with fairly simple optimizations. Unless you are doing
hundreds of thousands of context switches a second the overhead is in
the noise in real terms, and *definitely* in the noise if you tack on
a task switch in the middle of that.
Having the kernel do the context switch between threads has a huge number
of advantages that should outweight or at least equal the minor increase
in overhead. A couple of points that have been brought up in recent
emails:
* blockages due to VM faults
* blockages due to file I/O (not even network I/O)
* disk parallelism (thread A reads file block from kernel cache,
thread B reads file block and has a cache miss).
* event synchronization
* kernel state
Even if one were to use an asynchronous call gate one then has to deal
with the additional overhead imposed by the asynch call gate when a
syscall could have been run from the disk cache (that is, not block).
Personally speaking, I think async call gates are a huge mistake without
a prioritized, vectorable software interrupt mechanism to go along with
it. The current unix signal mechanism is simply not up to the task.
There are serious issues with async call gates including potential
resource hogging issues that frankly scare the hell out of me. I would
prefer a kernel stack for each thread and I would prefer a syscall to
set a thread runnable/not-runnable. Such a syscall could specify an
optional cpu and optional run interval.
There are simply too many things that a UP scheduler does not have access
to - such as knowing whether a syscall can complete without blocking or
not - to allow the UP scheduler to actually perform the context switch.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
