public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.8-rc1-np1
Date: Sat, 17 Jul 2004 19:25:58 +1000	[thread overview]
Message-ID: <40F8F0A6.8020003@yahoo.com.au> (raw)
In-Reply-To: <1090053943.1828.4.camel@teapot.felipe-alfaro.com>

Felipe Alfaro Solana wrote:
> On Sat, 2004-07-17 at 15:23 +1000, Nick Piggin wrote:
> 
> 
>>Scheduler behaviour is generally pretty good now so I've increased the
>>timeslice size to see how far I can push it. Some workloads really demand
>>small timeslices though, so I've added /proc/sys/kernel/base_timeslice.
>>If you have any problems with the default, please report it to me, and
>>check if lowering this value helps.
> 
> 
> On my 700Mhz Pentium III Mobile laptop, I feel that 256ms is too high
> for the system to keep interactive when a CPU hog is running. For

Yeah, it is probably a bit too large here too. A burst of activity
from X can cause xmms to skip slightly. Probably 128 or 64 would
be a decent default.

> example, running "while true; do a=2; done" makes the system pretty
> sluggish with the default timeslice. This is noticeable while dragging
> windows around (the movement is jerky and doesn't feel smooth).
> Decreasing the timeslie to 50ms, or even better, 25ms, makes the system
> behave much much better, although it will decrease throughput
> considerably, I guess.
> 

It usually isn't too bad for desktops, but is more important on
systems with more CPUs and bigger caches.

On this dual P3 with 256K L2 cache, a make -j8 vmlinux uses
162.16user 15.43system, ~150ctxsw/s with base_timeslice = 10000
163.88user 16.16system, ~300ctxsw/s with base_timeslice = 32
192.65user 17.27system, ~1300ctxsw/s with base_timeslice = 1

So you come to the point of diminishing returns very quickly, and
32 or even 16 or 8 are probably fine values for a desktop system
and worth the small cost for CPU intensive tasks.

  reply	other threads:[~2004-07-17  9:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-17  5:23 2.6.8-rc1-np1 Nick Piggin
2004-07-17  8:45 ` 2.6.8-rc1-np1 Felipe Alfaro Solana
2004-07-17  9:25   ` Nick Piggin [this message]
2004-07-17 20:52     ` 2.6.8-rc1-np1 Martin Schlemmer
2004-07-19 21:00 ` 2.6.8-rc1-np1 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=40F8F0A6.8020003@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=felipe_alfaro@linuxmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox