public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Peter Williams <peterw@aurema.com>
Cc: Timothy Miller <miller@techsource.com>,
	Mike Fedyk <mfedyk@matchmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] O(1) Entitlement Based Scheduler
Date: Fri, 27 Feb 2004 11:06:17 +0100	[thread overview]
Message-ID: <403F1699.5090404@aitel.hist.no> (raw)
In-Reply-To: <403E788A.8090100@aurema.com>

Peter Williams wrote:
> Timothy Miller wrote:
> 
>> How about this:
>>
>> The kernel tracks CPU usage, time slice expiration, and numerous other 
>> statistics, and exports them to userspace through /proc or somesuch. 
>> Then a user-space daemon adjusts priority.
> 
> 
> Yes, the right statistics could allow these processes to be identified 
> reasonably accurately.  The programs in question would have the 
> following characteristics:
> 
> 1. low CPU usage rate, and
> 2. a very regular pattern of use i.e. the size of each CPU bursts would 
> be approximately constant as would the size of the intervals between 
> each burst.

There is no need for the regularity.  When I use a word processor, I
use it very irregularly.  Sometimes I type text, and wants each letter
typed to appear instantly.  This fits well with "low cpu usage" and
sudden short bursts.  There may be lots of long delays though while
I think about stuff to write.  So the intervals are irregular, I still
believe I should get the boosts as long as the bursts are small.
Doing something big (such as invoking latex on a big document)
is cpu-heavy, but then it is ok not to get the boost.
Current schedulers based on io-waiting gets this right already.
> 
> The appropriate statistic to identify the second of these would be 
> variance or (equivalently but more expensively) standard deviation. 
> Whether this problem is bad/important enough to warrant the extra 
> overhead of gathering these statistics is a moot point.  We had to 
> generate very high system loads on a single CPU system in order to cause 
> one or two skips in xmms over a period of a couple of minutes.

Well, perhaps you could give a slightly bigge boost to a very regular
thing like xmms.  But even that might have some snags, the load
might change a lot when doing midi in software, depending on how
many instruments are active simultaneously. There goes the
constant-size bursts.

Helge Hafting


  reply	other threads:[~2004-02-27 10:09 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-25 14:35 [RFC][PATCH] O(1) Entitlement Based Scheduler John Lee
2004-02-25 17:09 ` Timothy Miller
2004-02-25 22:12   ` John Lee
2004-02-26  0:31     ` Timothy Miller
2004-02-26  2:04       ` John Lee
2004-02-26  2:18       ` Peter Williams
2004-02-26  2:42         ` Mike Fedyk
2004-02-26  4:10           ` Peter Williams
2004-02-26  4:19             ` Mike Fedyk
2004-02-26 19:23               ` Shailabh Nagar
2004-02-26 19:46                 ` Mike Fedyk
2004-02-26 20:42                   ` Shailabh Nagar
2004-02-26 16:10           ` Timothy Miller
2004-02-26 19:47             ` Mike Fedyk
2004-02-26 22:51             ` Peter Williams
2004-02-27 10:06               ` Helge Hafting [this message]
2004-02-27 11:04                 ` Peter Williams
2004-02-26 16:08         ` Timothy Miller
2004-02-26 16:51           ` Rik van Riel
2004-02-26 20:15           ` Peter Williams
2004-02-27 14:46             ` Timothy Miller
2004-02-28  5:00               ` Peter Williams
2004-03-04 21:18         ` Robert White
2004-03-04 23:15           ` Peter Williams
2004-02-26  2:48       ` Nuno Silva
2004-02-26  4:25         ` Peter Williams
2004-02-26 15:57           ` Rik van Riel
2004-02-26 19:28             ` Shailabh Nagar
2004-02-26 16:12         ` Timothy Miller
2004-02-25 22:51 ` Pavel Machek
2004-02-26  3:14   ` John Lee
2004-02-25 23:45 ` Rik van Riel
2004-02-26  7:18 ` John Lee
     [not found] <fa.f12rt3d.c0s9rt@ifi.uio.no>
     [not found] ` <fa.ishajoq.q5g90m@ifi.uio.no>
2004-02-25 23:33   ` Junio C Hamano
2004-02-26  8:15     ` Catalin BOIE
  -- strict thread matches above, loose matches on Subject: below --
2004-02-26  3:30 Albert Cahalan
2004-02-26  6:19 ` Peter Williams
2004-02-26 17:57   ` Albert Cahalan
2004-02-26 23:24     ` Peter Williams
2004-03-01  3:47       ` Peter Williams
     [not found] <1tfy0-7ly-29@gated-at.bofh.it>
     [not found] ` <1thzJ-A5-13@gated-at.bofh.it>
     [not found]   ` <1tjrN-2m5-1@gated-at.bofh.it>
     [not found]     ` <1tjLa-2Ab-9@gated-at.bofh.it>
     [not found]       ` <1tlaf-3OY-11@gated-at.bofh.it>
     [not found]         ` <1tljX-3Wf-5@gated-at.bofh.it>
     [not found]           ` <1tznd-CP-35@gated-at.bofh.it>
     [not found]             ` <1tzQe-10s-25@gated-at.bofh.it>
2004-02-26 20:14               ` Bill Davidsen
     [not found] <1t8wp-qF-11@gated-at.bofh.it>
     [not found] ` <1th6J-az-13@gated-at.bofh.it>
     [not found]   ` <403E2929.2080705@tmr.com>
2004-02-27  3:44     ` Rik van Riel
2004-02-28 21:27       ` Bill Davidsen
2004-02-28 23:55         ` Peter Williams
2004-03-04 21:08           ` Timothy Miller
     [not found] <fa.fi4j08o.17nchps@ifi.uio.no>
     [not found] ` <fa.ctat17m.8mqa3c@ifi.uio.no>
2004-02-29 11:58   ` Joachim B Haga
2004-02-29 20:39     ` Paul Jackson
2004-02-29 22:56     ` Peter Williams
     [not found] <894006121@toto.iv>
2004-03-01  0:00 ` Peter Chubb
2004-03-02  1:25   ` Peter Williams
     [not found] <fa.jgj0bdi.b3u6qk@ifi.uio.no>
2004-03-01  1:54 ` Andy Lutomirski
2004-03-01  2:54   ` Peter Williams
2004-03-01  3:46     ` Andy Lutomirski
2004-03-01  4:18       ` Peter Williams
2004-03-02 23:36   ` Peter Williams
     [not found] <fa.ftul5bl.nlk3pr@ifi.uio.no>
     [not found] ` <fa.cvc8vnj.ahebjd@ifi.uio.no>
2004-03-01  9:18   ` Joachim B Haga
2004-03-01 10:18     ` Paul Wagland
2004-03-01 19:11       ` Mike Fedyk
     [not found] <fa.fi4j08o.17nchps@ifi.uio.no.suse.lists.linux.kernel>
     [not found] ` <fa.ctat17m.8mqa3c@ifi.uio.no.suse.lists.linux.kernel>
     [not found]   ` <yydjishqw10p.fsf@galizur.uio.no.suse.lists.linux.kernel>
     [not found]     ` <40426E1C.8010806@aurema.com.suse.lists.linux.kernel>
2004-03-03  2:48       ` Andi Kleen
2004-03-03  3:45         ` Peter Williams
2004-03-03 10:13           ` Andi Kleen
2004-03-03 23:46             ` Peter Williams
2004-03-03 15:57           ` Andi Kleen
2004-03-04  0:41             ` Peter Williams
2004-03-05  3:55               ` Andi Kleen
     [not found] <1vuMd-5jx-5@gated-at.bofh.it>
     [not found] ` <1vuMd-5jx-7@gated-at.bofh.it>
     [not found]   ` <1vuMd-5jx-9@gated-at.bofh.it>
     [not found]     ` <1vuMd-5jx-11@gated-at.bofh.it>
     [not found]       ` <1vuMd-5jx-3@gated-at.bofh.it>
     [not found]         ` <1vvyx-6jy-13@gated-at.bofh.it>
     [not found]           ` <1vBE2-48V-21@gated-at.bofh.it>
2004-03-03 21:38             ` Bill Davidsen

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=403F1699.5090404@aitel.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=miller@techsource.com \
    --cc=peterw@aurema.com \
    /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