Ingo Molnar wrote: > now look at kevents as the queueing model. It does not queue 'tasks', it > lets user-space queue requests in essence, in various states. But it's > still the same conceptual thing: a memory buffer with some state > associated to it. Yes, it has no legacies, it has no priorities and > other queueing concepts attached to it ... yet. If kevents got > mainstream, it would get the same kind of pressure to grow 'more > advanced' event queueing and event scheduling capabilities. > Prioritization would be needed, etc.
But it would probably be tuned specifically to its use case, which would mean inherently better performance. > So my fundamental claim is: a kernel thread /is/ our main request > structure. We've got tons of really good system calls that queue these > 'requests' around the place and offer functionality around this concept. > Plus there's a 1.2+ billion lines of Linux userspace code that works > well with this abstraction - while there's nary a few thousand lines of > event-based user-space code. Think of the kernel scheduler as a default fallback scheduler, for procs that are randomly queued. Anytime you can identify a group of procs/threads that behave in a similar way, it's almost always best to do specific/private scheduling, for performance reasons. > I also say that you'll likely get kevents outperform threadlets. Maybe > even significantly so under the right conditions. But i very much > believe we want to get similar kind of performance out of thread/task > scheduling, and not introduce a parallel framework to do request > scheduling the hard way ... just because our task concept and scheduling > implementation got too fat. For the same reason i didnt really like > fibrils: they are nice, and Zach's core idea i think nicely survived in > the syslet/threadlet model too, but they are more limited than true > threads. So doing that parallel infrastructure, which really just > implements the same, and is only faster because it skips features, would > just be hiding the problem with our primary abstraction. Ok? Ok. But what you are proposing here is a dynamically plugable scheduler that is extensible on top of that. Sounds Great! Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/