Con Kolivas wrote:
On Wed, 11 Jan 2006 02:40 pm, Peter Williams wrote:
Con Kolivas wrote:
I disagree. I think the current implementation changes the balancing
according to nice much more effectively than previously where by their
very nature, low priority tasks were balanced more frequently and ended
up getting their own cpu.
I can't follow the logic here
cpu bound non interactive tasks have long timeslices. Tasks that have short
timeslices like interactive ones or cpu bound ones at nice 19 have short
timeslices.
Time slice size is dependent on nice (via static_prio) only, gets bigger
as static_prio gets smaller and only really effects the switching of
tasks from the active array to the expired array. This means that
programs with high nice values will tend to spend more time on the
expired array than the active array. Since the expired queue is always
examined first this makes them the most likely to be moved regardless of
the smp nice patch. This is independent of the amount of CPU a task
uses each time it gets onto the CPU which is what I think you were
alluding to.
If a nice 0 and nice 19 task are running on the same cpu, the
nice 19 one is going to be spending most of its time waiting in the runqueue.
As soon as an idle cpu appears it will only pull a task that is waiting in a
runqueue... and that is going to be the low priority tasks.
Because they're more likely to be on the expired array.
So the patch works by reducing the chance of any tasks being moved
during an idle rebalance. Surely this is likely to increase the amount
of idle time.
Maybe the idle balance should check the active arrays before it checks
the expired arrays? This will increase the chances of getting a high
priority task. The down side is that tasks on the active array are more
likely to be "cache warm" which is why the expired array is checked
first (hence the suggestion that this only apply to idle balancing).
But, as you say, let's wait and see what happens with the patch backed
out before we get too carried away.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
