Re: Allow migration of mlocked page?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 15 May 2012, Peter Zijlstra wrote:

> On Tue, 2012-05-15 at 09:12 -0500, Christoph Lameter wrote:
> > On Tue, 15 May 2012, Peter Zijlstra wrote:
> >
> > > So yes, page migration is a 'serious' problem, but only because the way
> > > its implemented is sub-optimal.
> >
> > For the low-latency cases: page migration needs to be restricted to cpus
> > that are allowed to run high latency tasks or restricted to a time that no
> > low-latency responses are needed by the app. This means during setup or
> > special processing times (maybe after some action was completed).
> >
> > A random compaction run can be very bad for a latency critical section.
>
> Yes however:
>
>  1) low latency doesn't make real-time, time bounds do.

Indeed. My requirements are low latency not real time deadlines. There is
some overlap but the basic idea on what to accomplish is different. F.e.
we cannot tolerate the overhead (and scaling limits) added through
additional logic coming with a "real time" kernel.

>  2) the latency impact of migration can be _MUCH_ improved if someone
> were to care about it.

True. I think THP/compaction would benefit most from it.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]