All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Con Kolivas <kernel@kolivas.org>
Cc: Jens Axboe <axboe@suse.de>, linux <linux-kernel@vger.kernel.org>
Subject: Re: time slice cfq comments
Date: Sat, 11 Dec 2004 10:16:17 +0100	[thread overview]
Message-ID: <20041211091617.GA22901@elte.hu> (raw)
In-Reply-To: <41BA2131.4040608@kolivas.org>


* Con Kolivas <kernel@kolivas.org> wrote:

> Hi Jens
> 
> Just thought I'd make a few comments about some of the code in your
> time sliced cfq.

(this code was actually a quick hack from me.)

> +	if (p->array)
> +		return min(cpu_curr(task_cpu(p))->time_slice,
> +					(unsigned int)MAX_SLEEP_AVG);
> 
> MAX_SLEEP_AVG is basically 10 * the average time_slice so this will
> always return task_cpu(p)->time_slice as the min value (except for the
> race you described in your comments). What you probably want is

the min() is there to not get ridiculous results due to the runqueue
race, nothing else. Basically i didnt want to lock the runqueue to do
something that is an estimation anyway, and rq->curr might be invalid. 
This was a proof-of-concept thing i wrote for Jens, if it works out then
i think we want to lock the runqueue nevertheless, to not dereference
possibly deallocated tasks (and to not trip up things like
DEBUG_PAGEALLOC).

> Further down you do:
> +	/*
> +	 * for blocked tasks, return half of the average sleep time.
> +	 * (because this is the average sleep-time we'll see if we
> +	 * sample the period randomly.)
> +	 */
> +	return NS_TO_JIFFIES(p->sleep_avg) / 2;
> 
> unfortunately p->sleep_avg is a non-linear value (weighted upwards 
> towards MAX_SLEEP_AVG). I suspect here you want
> 
> +	return NS_TO_JIFFIES(p->sleep_avg) / MAX_BONUS;

sleep_avg might be nonlinear, but nevertheless it's an estimation of the
sleep time of a task. It's different if the task is interactive. We
cannot know how much the task really will sleep, what we want is a good
guess. I didnt want to complicate things too much, as long as the
ballpark figure is right. (i.e. as long as the function returns '0' for
on-runqueue tasks, returns a large value for long sleepers and returns
something inbetween for short/medium sleepers.) We can later on
complicate it with things like looking at p->timestamp to figure out how 
long it has been sleeping (and thus the ->sleep_avg is perhaps not 
authorative anymore), but i kept it simple & stupid for now.

> I don't see any need for / 2.

the need for /2 is this: ->sleep_avg tells us the average _full_ sleep
period time (roughly). The CFQ IO-scheduler is sampling the task
_sometime_ during that period, randomly. So on average the task will
sleep another /2 of the sleep-average. Ok?

	Ingo

  parent reply	other threads:[~2004-12-11  9:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-10 22:20 time slice cfq comments Con Kolivas
2004-12-11  8:50 ` Jens Axboe
2004-12-11  9:16 ` Ingo Molnar [this message]
2004-12-11 13:55   ` Con Kolivas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041211091617.GA22901@elte.hu \
    --to=mingo@elte.hu \
    --cc=axboe@suse.de \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.