linux-kernel - Re: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon

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: <20110616223837.GA18431@elte.hu>
Date:	Fri, 17 Jun 2011 00:38:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Miller <davem@...emloft.net>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Russell King <rmk@....linux.org.uk>,
	Paul Mundt <lethal@...ux-sh.org>,
	Jeff Dike <jdike@...toit.com>,
	Richard Weinberger <richard@....at>,
	Tony Luck <tony.luck@...el.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>, Nick Piggin <npiggin@...nel.dk>,
	Namhyung Kim <namhyung@...il.com>, ak@...ux.intel.com,
	shaohua.li@...el.com, alex.shi@...el.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [GIT PULL] Re: REGRESSION: Performance regressions from
 switching anon_vma->lock to mutex


* Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> On Thu, 2011-06-16 at 22:25 +0200, Ingo Molnar wrote:
> 
> > > Whatever does the boosting will need to have process context 
> > > and can be subject to delays, so that pretty much needs to be a 
> > > kthread. But it will context-switch quite rarely, so should not 
> > > be a problem.
> > 
> > So user-return notifiers ought to be the ideal platform for that, 
> > right? We don't even have to touch the scheduler: anything that 
> > schedules will eventually return to user-space, at which point 
> > the RCU GC magic can run.
> > 
> > And user-return-notifiers can be triggered from IRQs as well.
> > 
> > That allows us to get rid of softirqs altogether and maybe even 
> > speed the whole thing up and allow it to be isolated better.
> 
> I'm a little worried of relying on things returning to userspace.
> 
> One could imagine something like a router appliance where userspace 
> is essentially asleep forever and everything happens in the kernel 
> (networking via softirq, maybe NFS kernel server, ...)

There's a crazy solution for that: the idle thread could process RCU 
callbacks carefully, as if it was running user-space code.

/me runs

Ok, joke aside: this is simply a special case where the idle thread 
generates RCU work via hardirqs. The idle thread is arguably special 
and could be handled in a special way: a helper thread that executes 
only in this case?

Thanks,

	Ingo
--
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/