Ingo Weinhold wrote: > It surprises me every time anew, how you manage to write a short novel on > a relatively compact topic. :-) :-) > On 2008-06-25 at 00:56:00 [+0200], André Braga <meianoite@xxxxxxxxx> > wrote: > [...] > > However, tracing is not the only way to know what code paths a process > > follows. When a process (or a thread) blocks, it blocks on a specific > > semaphore, a specific mutex, a specific condvar. We could use this > > knowledge to boost processes that we *know* to be interactive, because > > they blocked on a locking primitive that was declared on a code path > > that has to do with interactivity. But instead of feeding the scheduler > > with this information directly, we could make the process wakeup code > > itself adjust the process priority right before it gets inserted into > > the scheduler queues. As soon as this "privileged" scheduling round is > > finished, the process either blocks again on a locking primitive and > > gets boosted accordingly the next time it wakes up, or gets demoted > > back to its actual priority level. > > > > I believe this is an incredibly lightweight, robust and precise way to > > detect interactivity, since it's not based on any heuristics, but the > > actual code path a process follows. If said process sometimes behaves > > CPU-bound and sometimes behaves interactive, it won't be boosted at the > > wrong moments; this is much better than *trying* to predict the future > > by using some CPU usage history window. Not to mention that there's > > zero code overhead except for an extra private call that creates a > > branded semaphore, a single numeric variable that holds the desired > > boosting level, and a couple extra lines of code on the wakeup code > > that tweaks the priority prior to reinserting the thread on the > > scheduler queues. And the subsystems can be gradually modified to use > > branded locking primitives: nothing in the system will be disturbed at > > all, except that the more key locking primitives are converted, the > > more responsive the system gets. > > > > I actually can't find a single disadvantage in this approach. > > Well, it adds overhead. The main question is whether this kind of > optimization is necessary at all. As François already mentioned threads > that need very low latencies (and don't do much work) just get a high > priority. Analogously worker threads should be given priorities lower > than B_NORMAL_PRIORITY. IMHO when these simple rules are respected a > relatively fair scheduler would automatically schedule threads in such a > way that the interactive user experience is just fine. I agree with Ingo. Linux just has "nice levels" AFAIK, and I don't know how often or fine grained they are used. Thread priorities are fairly well understood and deployed in BeOS land. I've only ever come across one project where there was a misunderstanding and a 3D renderer was given a high priority. When I give a thread high priority I mean for it to wake up in a timely manner. The Haiku scheduler does not yet seem to perform very well in this regard. As you may know, I am working on the OSS media node at the moment. In BeOS, I can make the audio buffers quite short to achieve low latencies. The thread that feeds the buffers to the audio driver is run with very high priority, since the time variations that happen around when it wakes up to send the next buffer need to be lower than the buffer duration. On Haiku, I could also modify the OSS code to use smaller buffers, but as it turns out, Haiku is getting into trouble to wake up the thread at the right time when the system is busy otherwise. So I have to use large buffers to compensate for the wake up time variations. The resulting latency is quite bad. What I mean to say is this: The current scheduler needs more work, and I would try first to make thread priorities work well with regards to wakeup "variation". If this still does not yield nice results, we can think about other options. Though since BeOS could do with "just" the thread priorities, I would say it should be enough. As for whether or not this is desirable for R1 - I certainly think it is a must have. I don't know the involved code very much, but it looks like the scheduler should be a rather contained piece of code, so it's not like we are talking about changing lots of code with unforseen results. So please, by all means, work on it and experiment! :-) Best regards, -Stephan