On 14.06.2013 18:32, Christoph Lameter wrote:
On Fri, 14 Jun 2013, Roman Gushchin wrote:
Slub tries to allocate contiguous pages even if memory is fragmented and
there are no free contiguous pages. In this case it calls direct compaction
to allocate contiguous page. Compaction requires the taking of some heavily
contended locks (e.g. zone locks). So, running compaction (direct and using
kswapd) simultaneously on several processors can cause serious performance
issues.
The main thing that this patch does is to add a nocompact flag to the page
allocator. That needs to be a separate patch. Also fix the description.
Slub does not invoke compaction. The page allocator initiates compaction
under certain conditions.
Ok, I'll do.
It's possible to avoid such problems (or at least to make them less probable)
by avoiding direct compaction. If it's not possible to allocate a contiguous
page without compaction, slub will fall back to order 0 page(s). In this case
kswapd will be woken to perform asynchronous compaction. So, slub can return
to default order allocations as soon as memory will be de-fragmented.
Sounds like a good idea. Do you have some numbers to show the effect of
this patch?
No.
It seems that any numbers here depend on memory fragmentation,
so it's not easy to make a reproducible measurement. If you have
any ideas here, you are welcome.
But there is an actual problem, that this patch solves.
Sometimes I saw the following issue on some machines:
all CPUs are performing compaction, system time is about 80%,
system is completely unreliable. It occurs only on machines
with specific workload (distributed data storage system, so,
intensive disk i/o is performed). A system can fall into
this state fast and unexpectedly or by progressive degradation.
This patch solves this problem.
Thank you for your comments and suggestions!
Regards,
Roman
--
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/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>