lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101001143546.GA6194@nowhere>
Date:	Fri, 1 Oct 2010 16:36:10 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"Wu, Xia" <xia.wu@...el.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Zhu, Daniel" <daniel.zhu@...el.com>,
	"Wang, Yong Y" <yong.y.wang@...el.com>
Subject: Re: unnecessary timer interrupt of slab.c and bdi tasks when the
	system is in sleep state

On Fri, Oct 01, 2010 at 07:22:10AM -0700, Van De Ven, Arjan wrote:
> > > > I found some unnecessary timer interrupts when the system enter
> > sleep state.
> > > > (1)     /mm/slab.c
> > > > cache_reap() clean up on allocated memory every 2s. If the system
> > is in sleep state, the system is waked-up when this timer expires. In
> > fact,
> > > > there isn't more slabs to been cleaned up in sleep state.
> > >
> > > Right. We could switch off the timer when idle without much of an
> > issue.
> > > The expiration of the caches wont occur and so we will have stale
> > objects
> > > on the queues when we exit sleep state. You could flush the queues
> > before
> > > switching off the timers?
> > 
> > 
> > May be flushing the queue everytime we enter nohz is too much, as that
> > can
> > happen very often?
> > 
> 
> 
> the slab timer is already deferable... which means it won't hit while the system is completely idle.


I'm not sure what you mean exactly. The slab work seems to be scheduled strictly
periodically, unless the cpu goes offline. But I can't find any nohz-wise adaptation.



> I think this part of the original report is a red herring found on an older kernel.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ