Thread (20 messages) 20 messages, 5 authors, 2012-06-29

Re: needed lru_add_drain_all() change

From: Minchan Kim <minchan@kernel.org>
Date: 2012-06-27 00:55:04

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. 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?



-- 
Kind regards,
Minchan Kim

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help