On Wed, 27 Jun 2012 14:41:39 +0900 Minchan Kim [off-list ref] wrote:

On 06/27/2012 02:12 PM, Andrew Morton wrote:

quoted

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.

There's no way of fixing this without significantly degrading the
service which rt priority offers.  As we don't wish to degrade that
service, schedule_work_on() and schedule_on_each_cpu() cannot be
implemented reliably.  So we delete them.

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