Patches for threads/scheduler abstraction.

[Terry Lambert]

Jeff Roberson wrote:
> Terry, you're frustrating me.  So many of these comments are off the mark
> that I'm not going to address them.  You continue to demonstrate that you
> don't know what you're talking about and yet you feel the need to tell me
> how it is.
> 
> I know you're smart enough to get it but right now you're not getting it.

You are complaining about having a scheduler per threading
model as a result of having the KSE stuff around in the
kernel, and having to swap out files as a result, and
getting a multiplicity of kernels.

Fine.  I agree.

Let me think out loud, state my conclusions, and show my work
so that there will be crystal clarity, and neither you nor I
will end up frustrated.

If my understanding is flawed, then I will accept corection
willingly.


Right now, there are two schedulers and two threading models.

Worst case, this gives you 4 kernels.

You want to make this 2 kernels, by making the threading models
coexist, and the schedulers not coexist.

It's also possible to make this 2 kernels by making the schedulers
coexist and the threading models not coexist.


Now what I'm saying, which is frustrating you because you do
not want to hear it is that it's possible to have 1 kernel,
by making both the threading models and the schedulers coexist.


For this to work you can't pass around "processes", you have to
pass around these abstract things that contain a scheduler specific
part and a threading model specific part, and which are opaque to
the scheduler API, as far as the threading model goes, and opaque
to the threading API, as far as the scheduling model goes.


I can understand your point of view here: you want a cleaner API.


Have I made myself clear so far?  I don't want any misunderstanding.


Now to me, this means that when you create a process, you end
up with something attached to it that is threading model specific,
and something else attached to it that is scheduler specific.


Historically, for the SMPng stuff that supports an N:M model,
we've called these things "KSE" and "KSEGRP", specifically, and
we've *assumed* a scheduler implementation that operates on the
basis of "KSEGRP".  I don't like the abstraction, but I can see
the necessity for supporting multiple threading models, if that's
what you want to be able to do.


Personally, I don't care *what* they are called any more; the
issue that's the problem here is that the thing you want to
pass around in the scheduler API pretty much doesn't permit
per-threading model information in the container object.


Perhaps my understanding of your proposal is flawed; if that's
the case, then I'd like to be educated, rather than dismissed
with no explanation as to what I can do to correct my understanding.

Thanks,
-- Terry