On Tue, 8 May 2007, Jiri Slaby wrote:
> Yes, it helped, thanks. If no objections, please apply the patch below.
Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
e re-start
> > > vmstat_update() immediately.
> > >
> > > This is a bug, but I am not sure is this the only problem.
> >
> > In case I was not clear, this _can_ explain the problem. Because an extra
> > start_cpu_timer() (due to missed "break;") re-initi
ase I was not clear, this _can_ explain the problem. Because an extra
> start_cpu_timer() (due to missed "break;") re-initializes dwork, and clears
> _PENDING.
Yes, it helped, thanks. If no objections, please apply the patch below.
--
vmstat-use-our-own-tim
apply the patch below.
--
vmstat-use-our-own-timer-events-fix
add missing break
Cc: Christoph Lameter [EMAIL PROTECTED]
Cc: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit e0fe3cf4776a3c16ac7625ce9eae75ea42eb9b4e
tree
_PENDING.
Yes, it helped, thanks. If no objections, please apply the patch below.
Great! Thanks.
vmstat-use-our-own-timer-events-fix
add missing break
Cc: Christoph Lameter [EMAIL PROTECTED]
Cc: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit
On Tue, 8 May 2007, Jiri Slaby wrote:
Yes, it helped, thanks. If no objections, please apply the patch below.
Acked-by: Christoph Lameter [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Wed, 2 May 2007, Pallipadi, Venkatesh wrote:
> Can this use 'deferrable timer' along with round_jiffies. That
> will eliminate the issue of too frequent interrupt when CPU is idle.
Yes I asked Arjan about this.
> >+struct delayed_work *vmstat_work = _cpu(vmstat_work, cpu);
> >+
> >+
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Christoph Lameter
>Sent: Saturday, April 28, 2007 10:09 PM
>To: [EMAIL PROTECTED]
>Cc: linux-kernel@vger.kernel.org; Arjan van de Ven
>Subject: vmstat: use our own ti
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christoph Lameter
Sent: Saturday, April 28, 2007 10:09 PM
To: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org; Arjan van de Ven
Subject: vmstat: use our own timer events
We could implement
On Wed, 2 May 2007, Pallipadi, Venkatesh wrote:
Can this use 'deferrable timer' along with round_jiffies. That
will eliminate the issue of too frequent interrupt when CPU is idle.
Yes I asked Arjan about this.
+struct delayed_work *vmstat_work = per_cpu(vmstat_work, cpu);
+
+
On Mon, 30 Apr 2007, Arjan van de Ven wrote:
> > 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
>
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
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
On Mon, 30 Apr 2007, Arjan van de Ven wrote:
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
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?
>
>
On Sat, 28 Apr 2007 22:09:04 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> vmstat is currently using the cache reaper to periodically bring the
> statistics up to date. The cache reaper does only exists in SLUB
> as a way to provide compatibility with SLAB. This patch removes
> the
On Sat, 28 Apr 2007 22:09:04 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
vmstat is currently using the cache reaper to periodically bring the
statistics up to date. The cache reaper does only exists in SLUB
as a way to provide compatibility with SLAB. This patch removes
the vmstat
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
vmstat is currently using the cache reaper to periodically bring the
statistics up to date. The cache reaper does only exists in SLUB
as a way to provide compatibility with SLAB. This patch removes
the vmstat calls from the slab allocators and provides its own
handling.
The advantage is also that
vmstat is currently using the cache reaper to periodically bring the
statistics up to date. The cache reaper does only exists in SLUB
as a way to provide compatibility with SLAB. This patch removes
the vmstat calls from the slab allocators and provides its own
handling.
The advantage is also that
20 matches
Mail list logo
