Re: needed lru_add_drain_all() change

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 27 Jun 2012 14:41:39 +0900 Minchan Kim <minchan@kernel.org> wrote:

> On 06/27/2012 02:12 PM, Andrew Morton wrote:
> 
> > On Wed, 27 Jun 2012 11:09:31 +0900 Minchan Kim <minchan@kernel.org> wrote:
> > 
> >> On 06/27/2012 10:15 AM, Andrew Morton wrote:
> >>
> >>>> 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.
> >>
> >>
> >> 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>