Re: [PATCH v5 07/14] mm, compaction: khugepaged should not give up due to need_resched()

From: Vlastimil Babka
Date: Wed Jul 30 2014 - 05:08:37 EST

On 07/30/2014 12:53 AM, David Rientjes wrote:
On Tue, 29 Jul 2014, Vlastimil Babka wrote:

I think there's two ways to go about it:

- allow a single thp fault to be expensive and then rely on deferred
compaction to avoid subsequent calls in the near future, or

- try to make all thp faults be as least expensive as possible so that
the cumulative effect of faulting large amounts of memory doesn't end
up with lengthy stalls.

Both of these are complex because of the potential for concurrent calls to
memory compaction when faulting thp on several cpus.

I also think the second point from that email still applies, that we
should abort isolating pages within a pageblock for migration once it can
no longer allow a cc->order allocation to succeed.

That was the RFC patch 15, I hope to reintroduce it soon.

Which of the points above are you planning on addressing in another patch?
I think the approach would cause the above to be mutually exclusive

Oh I meant the quick abort of a pageblock that's not going to succeed. That was the RFC patch. As for the single expensive fault + defer vs lots of inexpensive faults, I would favor the latter. I'd rather avoid bug reports such as "It works fine for a while and then we get this weird few seconds of stall", which is exactly what you were dealing with IIRC?

You could still test
it meanwhile to see if you see the same extfrag regression as me. In my tests,
kswapd/khugepaged wasn't doing enough work to defragment the pageblocks that
the stress-highalloc benchmark (configured to behave like thp page fault) was

The initial regression that I encountered was on a 128GB machine where
async compaction would cause faulting 64MB of transparent hugepages to
excessively stall and I don't see how kswapd can address this if there's
no memory pressure and khugepaged can address it if it has the default
settings which is very slow.

Hm I see. I have been thinking about somehow connecting compaction with the extfrag (page stealing) events. For example, if it's about to allocate UNMOVABLE/RECLAIMABLE page in a MOVABLE pageblock, then try to compact the pageblock first, which will hopefully free enough of it to have it remarked as UNMOVABLE/RECLAIMABLE and satisfy many such allocations without having to steal from another one.

Another idea I had is to only do async memory compaction for thp on local
zones and avoid defragmenting remotely since, in my experimentation,
remote thp memory causes a performance degradation over regular pages. If
that solution were to involve zone_reclaim_mode and a test of
node_distance() > RECLAIM_DISTANCE, I think that would be acceptable as

Yes, not compacting remote zones on page fault definitely makes sense. Maybe even without zone_reclaim_mode...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at