Re: [PATCH 0/1] mm, compaction: correct the bounds of __fragmentation_index()

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

 





On 19 Feb 2018, at 08:24, Michal Hocko <mhocko@xxxxxxxxxx> wrote:

On Sun 18-02-18 16:47:54, robert.m.harris@xxxxxxxxxx wrote:
From: "Robert M. Harris" <robert.m.harris@xxxxxxxxxx>

__fragmentation_index() calculates a value used to determine whether
compaction should be favoured over page reclaim in the event of
allocation failure.  The function purports to return a value between 0
and 1000, representing units of 1/1000.  Barring the case of a
pathological shortfall of memory, the lower bound is instead 500.  This
is significant because it is the default value of
sysctl_extfrag_threshold, i.e. the value below which compaction should
be avoided in favour of page reclaim for costly pages.

Here's an illustration using a zone that I fragmented with selective
calls to __alloc_pages() and __free_pages --- the fragmentation for
order-1 could not be minimised further yet is reported as 0.5:

Cover letter for a single patch is usually an overkill. Why is this
information not valuable in the patch description directly?

This is my first patch and I’m not familiar with all the conventions.
I’ll incorporate those details in the next version of the commit message.

Robert Harris

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

  Powered by Linux