> > + 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/