Messages in this thread | | | Date | Wed, 21 Oct 1998 09:17:40 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: scheduler bigpatch is out |
| |
On Wed, 21 Oct 1998, Richard Gooch wrote: > Rik van Riel writes: > > /* Do we need to re-calculate counters? */
> > + p = init_task.next_run; > > + while (p != &init_task) { > > + p->counter >>= 1; > > + if (p->policy == SCHED_OTHER) > > + p->counter += p->priority; > > + else /* SCHED_IDLE, long slices */ > > + p->counter += 499; > > + p = p->next_run; > > + }
> I'm not keen on this approach. It adds an extra memory load and > test/branch for each process on the run queue. The extra load is the > most damaging, because we hit cache line aliasing problems.
Remember that we calculate the priority of far less programs than what we used to do... But I agree that it would be better if we had p->policy, p->priority, p->counter and the various other priority-related stuff on the same cache line.
I guess we could do that in a very cheap way, so we can keep the feature and lose the big cost.
> Instead of doing it this way, why not make use of the facility I > added with the RT run queue patch and create another run queue for > idle/batch processes?
I could do that, but that would mean having to recalculate the counters from two queues as well. I guess you want it your way and your way might actually have a little lower overhead, so I will put up a new version of my patch this afternoon.
> You would then add a single test/branch operation after the scan of > the SCHED_OTHER run queue to see if you should scan the SCHED_BATCH > (I prefer that name to SCHED_IDLE:-) queue.
It is SCHED_IDLE, and definately not SCHED_BATCH. SCHED_BATCH suggests a batch queue mechanism, not a mechanism for running tasks when nothing else wants to run...
> Of course, you'd also have to "store" the pointer to the start > of the batch queue just like with the RT and SCHED_OTHER queues.
Yes.
> This has the following advantages: > > - no code or memory references added to critical queue scan path
True.
> - batch processes are isolated from SCHED_OTHER, which means an > unlimited number of batch processes don't affect normal interactive > scheduling (same argument with RT run queue).
They already are pretty much isolated, except for the fact that they share the same run queue and get recalculated at the same time as normal processes.
The problem still is with process priority calculation, but I think we can solve that pretty easily as well.
> I'd also suggest making the default timeslice for batch processes 1 > second.
If we separate the queues, why not make the batch processes roundrobin scheduled [if(p->counter == 0) move_last_runqueue(p)] with a sysctl tuneable timeslice lenght ;)
Expect a new patch very very soon...
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |