linux-kernel - Re: [PATCH -mm v2] vmscan: move reclaim_state handling to shrink

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] [day] [month] [year] [list]

Date:	Tue, 20 Jan 2015 11:11:20 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Vladimir Davydov <vdavydov@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Vlastimil Babka <vbabka@...e.cz>, Mel Gorman <mgorman@...e.de>,
	Rik van Riel <riel@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm v2] vmscan: move reclaim_state handling to shrink_slab

On Mon 19-01-15 23:35:50, Paul E. McKenney wrote:
> On Thu, Jan 15, 2015 at 03:48:38PM +0100, Michal Hocko wrote:
> > On Thu 15-01-15 16:25:16, Vladimir Davydov wrote:
[...]
> > > Does RCU free objects from irq or soft irq context?
> > 
> > and this is another part which I didn't consider at all. RCU callbacks
> > are normally processed from kthread context but rcu_init also does
> > open_softirq(RCU_SOFTIRQ, rcu_process_callbacks)
> > so something is clearly processed from softirq as well. I am not
> > familiar with RCU details enough to tell how many callbacks are
> > processed this way. Tiny RCU, on the other hand, seem to be processing
> > all callbacks via __rcu_process_callbacks and that seems to be processed
> > from softirq only.
> 
> RCU invokes all its callbacks with BH disabled, either because they
> are running in softirq context or because the rcuo kthreads disable
> BH while invoking each callback.  When running in softirq context,
> RCU will normally invoke only ten callbacks before letting the other
> softirq vectors run.  However, if there are more than 10,000 callbacks
> queued on a given CPU (which can happen!), RCU will go into panic mode
> and just invoke the callbacks as quickly as it can.

Thanks for the clarification, Paul! This means that not only drivers
might free some memory but also kfree called from RCU context would do
so this adds potentially even more memcg unrelated noise.
 
> You can of course have your callback schedule a work-queue item or
> wake up a kthread to avoid this tradeoff.
> 
> 							Thanx, Paul
-- 
Michal Hocko
SUSE Labs
--
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/