Date: Thu, 17 Apr 2003 10:59:00 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-threads@freebsd.org Subject: Re: Patches for threads/scheduler abstraction. Message-ID: <3E9EEB64.A193DB99@mindspring.com> References: <20030417131733.D76635-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9EEB64.A193DB99>