From: Con Kolivas <kernel@kolivas.org>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH][2.6.6] Replacing CPU scheduler active and expired with a single array
Date: Mon, 31 May 2004 09:13:32 +1000 [thread overview]
Message-ID: <1085958812.40ba6a9c828f6@vds.kolivas.org> (raw)
In-Reply-To: <40BA7683.2000501@bigpond.net.au>
Quoting Peter Williams <pwil3058@bigpond.net.au>:
> Con Kolivas wrote:
> > The interactive credit?
>
> No. I was asking about the mechanism in schedule() that, based on the
> value of "activated", allows some tasks to count their time on the run
> queue as sleep time.
No this is different again. When there is significant load and an interactive
task (like X) is using bursts of cpu it will not get a chance to sleep. It will
either run out of timeslice or be preempted and thus will be constantly on the
runqueue. In that time if only sleep time is counted it is progressively seen
as a cpu bound task - in fact this was a major problem before where X would
basically die under load because you'd move a window and it would be constantly
waiting for more cpu time rather than ever sleeping.
> I also think that their is a category of task that may be automatically
> detected and that needs special attention and that is tasks that need
> very regular access to small bursts of CPU. I suspect that the tasks
> doing the mpeg and divx encoding/decoding that you refer to above fall
> into this category. The key to identifying these tasks would be that
> the variance (or standard deviation) of their sleeps would be close to
> zero and as they probably do much the same amount of work each CPU burst
> the same would be true of the variance of the length of the CPU bursts.
I've already tried that experiment and I personally failed to make the pattern
of sleep/burst correspond with interactivity. There is a huge variation in the
duration of sleep/run for all different things, and it changes with load. Of
course your modelling may be better than mine.
> Dr Peter Williams pwil3058@bigpond.net.au
Oooh I've got one of those too but I normally dont use it on lkml.
So just for this once...
Dr Con Kolivas
next prev parent reply other threads:[~2004-05-31 1:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-29 5:27 Peter Williams
2004-05-29 11:17 ` Con Kolivas
2004-05-30 0:19 ` Peter Williams
2004-05-30 12:56 ` Con Kolivas
2004-05-31 0:04 ` Peter Williams
2004-05-30 23:13 ` Con Kolivas [this message]
[not found] <214A1-6NK-7@gated-at.bofh.it>
[not found] ` <21acm-2GN-1@gated-at.bofh.it>
2004-05-29 12:24 ` Andi Kleen
2004-05-29 12:38 ` Con Kolivas
2004-06-04 7:40 ` Peter Williams
-- strict thread matches above, loose matches on Subject: below --
2004-05-29 1:39 Peter Williams
2004-05-28 4:52 Peter Williams
2004-05-28 9:05 ` Ingo Molnar
2004-05-28 9:24 ` Peter Williams
2004-05-28 9:29 ` Ingo Molnar
2004-05-28 9:57 ` 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=1085958812.40ba6a9c828f6@vds.kolivas.org \
--to=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pwil3058@bigpond.net.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®