From: Andi K. <ak...@su...> - 2001-02-12 10:18:51
|
On Mon, Feb 12, 2001 at 05:14:02AM +0000, Andrew Morton wrote: > > As a reminder, the multi-queue scheduler I am working on > > has one runqueue per CPU. In addition, there is a separate > > runqueue lock per CPU which synchronizes access to the the > > CPU specific runqueue. In schedule(), the runqueue lock > > associated with the CPU we are currently running on is > > obtained. Then the CPU specific runqueue is scanned looking > > for the task with the highest 'goodness' value. After > > scanning the CPU specific runqueue, we 'take a quick look' > > at other the other runqueues to determine if there is a task > > with higher goodness that should be scheduled. > > Apologies for not having read the MQ scheduler patch, but... > > How can you safely "peek" at a task without locking it down > somehow? Under the current (2.4.1) design, you have to lock [...] The quick look just looks at a precomputed goodness value for other runqueues, so it costs you a single cache line transfer. If the goodness looks promising it locks the other runqueue and steals a task. If you wanted to do it fully you could also use delayed freeing, as described in the rclock documentation posted here a few weeks ago. Then you could walk all the lists lockless. Of course that would cost a few more cache lines of transfer. _Andi |