fixed timeslice

fixed timeslice

[Jason mclaughlin]

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?

Re: fixed timeslice

[Peter Zijlstra]

On Mon, 2009-05-11 at 09:58 -0400, Jason mclaughlin 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?

I'm rather confused. If a task is blocked on IO its not contending for
CPU resources and is thus irrelevant to the running tasks and their
fairness.

Also, only SCHED_RR has a fixed timeslice.

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@gmail.com> 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?
>