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 05:41:34

On 06/27/2012 02:12 PM, Andrew Morton wrote:
On Wed, 27 Jun 2012 11:09:31 +0900 Minchan Kim [off-list ref] wrote:
quoted
On 06/27/2012 10:15 AM, Andrew Morton wrote:
quoted
quoted
Considering mlock and CPU pinning
quoted
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.

Yeb but I'm not sure such system modeling is good.
Potentially, It could make problem once we use workqueue of other CPU.
whut?

My suggestion is that we switch lru_add_drain_all() to on_each_cpu()
and delete schedule_on_each_cpu().  No workqueues.

Current problem is that RT thread doesn't yield his CPU so other tasks can't be scheduled in.
schedule_on_each_cpu uses system workqueue so if there are any user to try using
workqueue for the CPU(ex, schedule_work_on), he can make trouble, too.
So my question is I doubt such greedy RT thread modeling is good.

Do I miss something?

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