:> > blocked in the kernel, whereas with scheduler activations (SA), that
:> > doesn't happen under normal circumstances.
:> No, under SA KSE's block. and another KSE is generated to act as a
:> replacement. it is used to run the activation that is passed to the
:> scheduler, and this the next thread the process runs.
:That's not how I read the paper. I think we all might be on the 'same
:page', but I think we're all using different terminology.
:How's about we define what a KSE is, a SA is, and come up with some
:other term for a userland 'thread'?
:It seems that Julian is using the same term for a userland thread and a
:context that can go into the userland as a KSE, but I'm not sure.
:Assuming for a moment that this is the case, then is a SA a 'kernel
The terminology I have been using, which I thought was the same as
Julian's but may not be, is:
Two entities. A kernel structure 'Thread' and also a similarly
named but independant user structure within the UTS.
A kernel scheduleable entity. I was using this to mean the
contextual information (such as a kernel stack) required for
the kernel to be able to run a thread. Not required for
runnability, only required to actually run the thread and
also held over of the thread blocks while in the kernel.
Our good old process.
I think I actually misspoke earlier. Runnability in the kernel scheduler
is governed by 'Thread', not 'KSE' with my idea. Only currently running
contexts require a KSE. i.e. you might have 10 runnable Threads linked
into the kernel's scheduler but if you have a two-cpu system, only 2 of
those 10 will actually be running at any given moment and require KSE's.
With my system we change the kernel scheduling entity from a 'Process'
to a 'Thread' and a Thread can then optionally (dynamically) be assigned
a KSE as required to actually run. The KSE is a kernel abstraction and
essentially *invisible* to user mode. The Thread is a kernel abstraction
that is visible to user mode.
With Julian's idea the kernel scheduling entity remains a 'Process',
KSE's are special cases within that process, and Threads appear to
be entirely userland entities.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message