From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx131.postini.com [74.125.245.131]) by kanga.kvack.org (Postfix) with SMTP id A72DB6B005A for ; Tue, 26 Jun 2012 21:14:02 -0400 (EDT) Date: Tue, 26 Jun 2012 18:15:04 -0700 From: Andrew Morton Subject: Re: needed lru_add_drain_all() change Message-Id: <20120626181504.23b8b73d.akpm@linux-foundation.org> In-Reply-To: <4FEA59EE.8060804@kernel.org> References: <20120626143703.396d6d66.akpm@linux-foundation.org> <4FEA59EE.8060804@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, KOSAKI Motohiro On Wed, 27 Jun 2012 09:55:10 +0900 Minchan Kim wrote: > On 06/27/2012 06:37 AM, Andrew Morton wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=43811 > > > > lru_add_drain_all() uses schedule_on_each_cpu(). But > > schedule_on_each_cpu() hangs if a realtime thread is spinning, pinned > > to a CPU. There's no intention to change the scheduler behaviour, so I > > think we should remove schedule_on_each_cpu() from the kernel. > > > > The biggest user of schedule_on_each_cpu() is lru_add_drain_all(). > > > > Does anyone have any thoughts on how we can do this? The obvious > > approach is to declare these: > > > > static DEFINE_PER_CPU(struct pagevec[NR_LRU_LISTS], lru_add_pvecs); > > static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs); > > static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs); > > > One more > static DEFINE_PER_CPU(struct pagevec, activate_page_pvecs); > > > > > to be irq-safe and use on_each_cpu(). lru_rotate_pvecs is already > > irq-safe and converting lru_add_pvecs and lru_deactivate_pvecs looks > > pretty simple. > > > Yes. Changing looks simple. > I'm okay with lru_[activate_page|deactivate]_pvecs because it's not hot > but lru_rotate_pvecs is hotter than others. I don't think any change is needed for lru_rotate_pvecs? > Considering mlock and CPU pinning > of realtime thread is very rare, it might be rather expensive solution. > Unfortunately, I have no idea better than you suggested. :( > > And looking 8891d6da17, mlock's lru_add_drain_all isn't must. > If it's really bother us, couldn't we remove it? "grep lru_add_drain_all mm/*.c". They're all problematic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org