On Wed, 27 Jun 2012 09:55:10 +0900 Minchan Kim <minchan@xxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>