On 01/05/2017 11:27 AM, Michal Hocko wrote:

On Thu 05-01-17 10:53:59, Vlastimil Babka wrote:

quoted

quoted

quoted

Therefore I believe we need a watermark based pro-active compaction
which would keep the background compaction busy as long as we have
less pages of the configured order.

Again, configured by what, admin? I would rather try to avoid tunables
here, if possible. While THP is quite well known example with stable
order, the pressure for other orders is rather implementation specific
(drivers, SLAB/SLUB) and may change with kernel versions (e.g. virtually
mapped stacks, although that example is about non-costly order). Would
the admin be expected to study the implementation to know which orders
are needed, or react to page allocation failure reports? Neither sounds
nice.

That is a good question but I expect that there are more users than THP
which use stable orders. E.g. networking stack tends to depend on the
packet size. A tracepoint with some histogram output would tell us what
is the requested orders distribution.

Maybe, but there might be also multiple users of the same order but
different "importance"...

quoted

quoted

quoted

kcompactd should wake up
periodically, I think, and check for the status so that we can catch
the fragmentation before we get low on memory.
The interface could look something like:
/proc/sys/vm/compact_wmark
time_period order count

IMHO it would be better if the system could auto-tune this, e.g. by
counting high-order alloc failures/needs for direct compaction per order
between wakeups, and trying to bring them to zero.

auto-tunning is usually preferable I am just wondering how the admin can
tell what is still the system load price he is willing to pay. I suspect
we will see growing number of opportunistic high order requests over
time and  auto tunning shouldn't try to accomodate with it without
any bounds.There is still some cost/benefit to be evaluated from the
system level point of view which I am afraid is hard to achive from the
kcompactd POV.

That's why I mentioned that importance should be judged somehow.
Opportunistic requests should be recognizable by their gfp flags, so
hopefully there's a way. I wouldn't mind some general tunable(s) to
express how much effort to give to "important" allocations and
opportunistic ones, but rather not in such implementation-detail form as
"time_period order count".

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