From: Arjan van de Ven <arjan@linux.intel.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: vmstat: use our own timer events
Date: Mon, 30 Apr 2007 07:12:08 -0700 [thread overview]
Message-ID: <4635F938.3060706@linux.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0704292138480.1737@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Sun, 29 Apr 2007, Andrew Morton wrote:
>
>>> on each node at the second and then each of the other processor on a
>>> node on a subsequent tick. That may be useful to keep a large amount
>>> of the second free of timer activity. Maybe the timer folks will have
>>> some feedback on this one?
>> The one-per-second timer interrupt will upset the people who are really
>> aggressive about power consumption (eg, OLPC). Perhaps there isn't (yet)
>> an intersection between those people and SMP.
>
> Well the cache_reaper of SLAB hits hard todays anyways. This will help
> if they switch to slub because the counter consolidation is much lighter
> weight.
it's not about the weight. It's about waking up *at all*. I've been working
really hard to get a system with a reasonable average idle time (600ms+), but
I obviously had to patch the SLAB reaper to be at a different resolution...
>
> I am fine with delaying this. I just wanted the timer guys to have a
> chance to shape this a bit. Not sure what they want. What they did to the
> cache_reaper in 2.6.20/21 is bad.
HUH? The cache_reaper DID NOT CHANGE with the round_jiffies() change.
Before it had a 3 jiffies per cpu offset, after it has a 3 jiffies per cpu offset.
next prev parent reply other threads:[~2007-04-30 14:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-29 5:09 vmstat: use our own timer events Christoph Lameter
2007-04-29 8:15 ` Andrew Morton
2007-04-30 4:44 ` Christoph Lameter
2007-04-30 14:12 ` Arjan van de Ven [this message]
2007-04-30 17:42 ` Christoph Lameter
2007-05-02 18:13 ` Pallipadi, Venkatesh
2007-05-02 18:29 ` Christoph Lameter
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=4635F938.3060706@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--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