Re: fixed timeslice

[Jason mclaughlin]

doesn't it work out that scheduling fairness is accomplished by
ready-to-run and next-in-line?

so when is it the turn to have your next-in-line when you're ready to
run? when something else is done before, right?

so what opportunity does something want to have when it's ready to
run? it's when it comes up in line.
so what is the change of being available to run right away when IO
finishes and you can have your read succeed?
isn't it when something is done before sometimes?

can what's before use as much time as a timeslice though?

ok..

so if so,

isn't it scheduling on-time opportunity that matters the most for IO?

so when a read is successful, it's time to run right away, to do
another read perhaps.

because that's when it's stop-go for IO.

so scheduling can't always make opportunity to run when IO is
successful right? sometimes though.
but isn't what's before that's running now maybe a whole timeslice?
but with the same fairness to run?

can't this make it so IO schedules with a timeslice between stop-go?






On Mon, May 11, 2009 at 9:58 AM, Jason mclaughlin <mcjason@xxxxxxxxx> wrote:
> can't scheduling be unfair when a fixed timeslice is used as the time
> up til a process can run?
>
> won't it work out that if a program is using the harddrive, and
> another is using cpu time and using up it's timeslices, that the
> cpu user will give less runtime opportunity to the harddrive user
> because of a wait up until timeslice to use the harddrive again?
>
> like, doesn't the length of a timeslice change the fairness of
> scheduling opportunity for harddrive use?
>
> can't it span the time that something is ready to take from the
> harddrive, til the time the harddrive can be used again?
>
> can't it anyways in some cases though no matter what, because of how
> using up til a timeslice is available sometimes when something wants
> to use the harddrive again,
> and because what wants to use the harddrive can be behind what uses a
> whole timeslice?
>
--
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/