Re: scheduler interactivity: timeslice calculation seem wrong

[Nick Piggin]

bill davidsen wrote:

> In article <3F41B43D.6000706@xxxxxxxxxxxxxxx>,
> Nick Piggin  <piggin@xxxxxxxxxxxxxxx> wrote:
> | Eric St-Laurent wrote:
>
> | >
> | >Anyway i always tought linux default timeslice of 100 ms is way too long
> | >for desktop uses. Starting with this in mind, i think that a 10 ms
> | >timeslice should bring back good interactive feel, and by using longer
> | >timeslices for (lower prio) cpu-bound processes, we can save some costly
> | >context switches.
> | >
> | 
> | I agree completely.
> | 
> | >
> | >Unfortunatly i'm unable to test those ideas right now but i share them,
> | >maybe it can help other's work.
> | >
> | >- (previously mentionned) higher prio tasks should use small timeslices
> | >and lower prio tasks, longer ones. i think, maybe falsely, that this can
> | >lower context switch rate for cpu-bound tasks. by using up to 200 ms
> | >slices instead of 10 ms...
> | >
> | >- (previously mentionned) use dynamic priority to calculate timeslice
> | >length.
> | >
> | >- maybe adjust the max timeslice length depending on how many tasks are
> | >running/ready.
> | >
> | 
> | I agree with your previous two points. Not this one. I think it is very
> | easy to get bad feedback loops and difficult to ensure it doesn't break
> | down under load when doing stuff like this. I might be wrong though.
>
> I have to agree with Eric that sizing the max timeslices to fit the
> hardware seems like a reasonable thing to do. I have little salvaged
> systems running (well strolling would be more accurate) Linux on old
> Pentium Classic 90-166MHz machines. I also have 3+ GHz SMP machines. I
> have a gut feeling that the timeslices need to be longer on the slow
> machines to allow them to get something done, that the SMP machines
> will perform best with a different timeslice than UP of the same speed,
> etc.

Well its just so hard to get right. If someone could demonstrate a
big performance improvement, then the scheduler might need fixing
anyway.

For example, on your machines, its very likely that your new machines
would benefit more from big timeslices than the old ones due to more
cache, quicker cpu to memory, multiple cpus...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/