All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	David Rientjes <rientjes@google.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 04/12] Export fragmentation index via /proc/pagetypeinfo
Date: Fri, 19 Feb 2010 00:37:57 +0900	[thread overview]
Message-ID: <1266507477.1709.225.camel@barrios-desktop> (raw)
In-Reply-To: <1265976059-7459-5-git-send-email-mel@csn.ul.ie>

On Fri, 2010-02-12 at 12:00 +0000, Mel Gorman wrote:
> Fragmentation index is a value that makes sense when an allocation of a
> given size would fail. The index indicates whether an allocation failure is
> due to a lack of memory (values towards 0) or due to external fragmentation
> (value towards 1).  For the most part, the huge page size will be the size
> of interest but not necessarily so it is exported on a per-order and per-zone
> basis via /proc/pagetypeinfo.
> 
> The index is normally calculated as a value between 0 and 1 which is
> obviously unsuitable within the kernel. Instead, the first three decimal
> places are used as a value between 0 and 1000 for an integer approximation.
> 
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

> ---
>  Documentation/filesystems/proc.txt |   11 ++++++
>  mm/vmstat.c                        |   63 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 0968a81..06bf53c 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -618,6 +618,10 @@ Unusable free space index at order
>  Node    0, zone      DMA                         0      0      0      2      6     18     34     67     99    227    485
>  Node    0, zone    DMA32                         0      0      1      2      4      7     10     17     23     31     34
>  
> +Fragmentation index at order
> +Node    0, zone      DMA                        -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
> +Node    0, zone    DMA32                        -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
> +
>  Number of blocks type     Unmovable  Reclaimable      Movable      Reserve      Isolate
>  Node 0, zone      DMA            2            0            5            1            0
>  Node 0, zone    DMA32           41            6          967            2            0
> @@ -639,6 +643,13 @@ value between 0 and 1000. The higher the value, the more of free memory is
>  unusable and by implication, the worse the external fragmentation is. The
>  percentage of unusable free memory can be found by dividing this value by 10.
>  
> +The fragmentation index, is only meaningful if an allocation would fail and
> +indicates what the failure is due to. A value of -1 such as in the example
> +states that the allocation would succeed. If it would fail, the value is
> +between 0 and 1000. A value tending towards 0 implies the allocation failed
> +due to a lack of memory. A value tending towards 1000 implies it failed
> +due to external fragmentation.
> +
>  If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
>  from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
>  make an estimate of the likely number of huge pages that can be allocated
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index d05d610..e2d0cc1 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -494,6 +494,35 @@ static void fill_contig_page_info(struct zone *zone,
>  }
>  
>  /*
> + * A fragmentation index only makes sense if an allocation of a requested
> + * size would fail. If that is true, the fragmentation index indicates
> + * whether external fragmentation or a lack of memory was the problem.
> + * The value can be used to determine if page reclaim or compaction
> + * should be used
> + */
> +int fragmentation_index(struct zone *zone,

Like previous [3/12], why do you remain "zone" argument?
If you will use it in future, I don't care. It's just trivial. 

-- 
Kind regards,
Minchan Kim



WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	David Rientjes <rientjes@google.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 04/12] Export fragmentation index via /proc/pagetypeinfo
Date: Fri, 19 Feb 2010 00:37:57 +0900	[thread overview]
Message-ID: <1266507477.1709.225.camel@barrios-desktop> (raw)
In-Reply-To: <1265976059-7459-5-git-send-email-mel@csn.ul.ie>

On Fri, 2010-02-12 at 12:00 +0000, Mel Gorman wrote:
> Fragmentation index is a value that makes sense when an allocation of a
> given size would fail. The index indicates whether an allocation failure is
> due to a lack of memory (values towards 0) or due to external fragmentation
> (value towards 1).  For the most part, the huge page size will be the size
> of interest but not necessarily so it is exported on a per-order and per-zone
> basis via /proc/pagetypeinfo.
> 
> The index is normally calculated as a value between 0 and 1 which is
> obviously unsuitable within the kernel. Instead, the first three decimal
> places are used as a value between 0 and 1000 for an integer approximation.
> 
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

> ---
>  Documentation/filesystems/proc.txt |   11 ++++++
>  mm/vmstat.c                        |   63 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 0968a81..06bf53c 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -618,6 +618,10 @@ Unusable free space index at order
>  Node    0, zone      DMA                         0      0      0      2      6     18     34     67     99    227    485
>  Node    0, zone    DMA32                         0      0      1      2      4      7     10     17     23     31     34
>  
> +Fragmentation index at order
> +Node    0, zone      DMA                        -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
> +Node    0, zone    DMA32                        -1     -1     -1     -1     -1     -1     -1     -1     -1     -1     -1
> +
>  Number of blocks type     Unmovable  Reclaimable      Movable      Reserve      Isolate
>  Node 0, zone      DMA            2            0            5            1            0
>  Node 0, zone    DMA32           41            6          967            2            0
> @@ -639,6 +643,13 @@ value between 0 and 1000. The higher the value, the more of free memory is
>  unusable and by implication, the worse the external fragmentation is. The
>  percentage of unusable free memory can be found by dividing this value by 10.
>  
> +The fragmentation index, is only meaningful if an allocation would fail and
> +indicates what the failure is due to. A value of -1 such as in the example
> +states that the allocation would succeed. If it would fail, the value is
> +between 0 and 1000. A value tending towards 0 implies the allocation failed
> +due to a lack of memory. A value tending towards 1000 implies it failed
> +due to external fragmentation.
> +
>  If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
>  from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
>  make an estimate of the likely number of huge pages that can be allocated
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index d05d610..e2d0cc1 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -494,6 +494,35 @@ static void fill_contig_page_info(struct zone *zone,
>  }
>  
>  /*
> + * A fragmentation index only makes sense if an allocation of a requested
> + * size would fail. If that is true, the fragmentation index indicates
> + * whether external fragmentation or a lack of memory was the problem.
> + * The value can be used to determine if page reclaim or compaction
> + * should be used
> + */
> +int fragmentation_index(struct zone *zone,

Like previous [3/12], why do you remain "zone" argument?
If you will use it in future, I don't care. It's just trivial. 

-- 
Kind regards,
Minchan Kim


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

  parent reply	other threads:[~2010-02-18 15:38 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-12 12:00 [PATCH 0/12] Memory Compaction v2r12 Mel Gorman
2010-02-12 12:00 ` Mel Gorman
2010-02-12 12:00 ` [PATCH 01/12] mm: Document /proc/pagetypeinfo Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-12 15:54   ` Christoph Lameter
2010-02-12 15:54     ` Christoph Lameter
2010-02-16  7:05   ` KOSAKI Motohiro
2010-02-16  7:05     ` KOSAKI Motohiro
2010-02-12 12:00 ` [PATCH 02/12] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA or memory hot-remove Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-16 17:43   ` Rik van Riel
2010-02-16 17:43     ` Rik van Riel
2010-02-12 12:00 ` [PATCH 03/12] Export unusable free space index via /proc/pagetypeinfo Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-16  7:03   ` KOSAKI Motohiro
2010-02-16  7:03     ` KOSAKI Motohiro
2010-02-16  8:36     ` Mel Gorman
2010-02-16  8:36       ` Mel Gorman
2010-02-16  8:41       ` KOSAKI Motohiro
2010-02-16  8:41         ` KOSAKI Motohiro
2010-02-16  8:50         ` Mel Gorman
2010-02-16  8:50           ` Mel Gorman
2010-02-16 18:28   ` Rik van Riel
2010-02-16 18:28     ` Rik van Riel
2010-02-18 15:23   ` Minchan Kim
2010-02-18 15:23     ` Minchan Kim
2010-02-18 15:32     ` Mel Gorman
2010-02-18 15:32       ` Mel Gorman
2010-02-12 12:00 ` [PATCH 04/12] Export fragmentation " Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-16  7:59   ` KOSAKI Motohiro
2010-02-16  7:59     ` KOSAKI Motohiro
2010-02-16  8:41     ` Mel Gorman
2010-02-16  8:41       ` Mel Gorman
2010-02-16  8:49       ` KOSAKI Motohiro
2010-02-16  8:49         ` KOSAKI Motohiro
2010-02-17  1:44   ` Rik van Riel
2010-02-17  1:44     ` Rik van Riel
2010-02-18 15:37   ` Minchan Kim [this message]
2010-02-18 15:37     ` Minchan Kim
2010-02-12 12:00 ` [PATCH 05/12] Memory compaction core Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-16  8:31   ` KOSAKI Motohiro
2010-02-16  8:31     ` KOSAKI Motohiro
2010-02-16  8:48     ` Mel Gorman
2010-02-16  8:48       ` Mel Gorman
2010-02-16 14:55       ` Christoph Lameter
2010-02-16 14:55         ` Christoph Lameter
2010-02-16 14:59         ` Mel Gorman
2010-02-16 14:59           ` Mel Gorman
2010-02-18 19:37           ` Christoph Lameter
2010-02-18 19:37             ` Christoph Lameter
2010-02-18 21:35             ` Mel Gorman
2010-02-18 21:35               ` Mel Gorman
2010-02-19  0:04             ` KAMEZAWA Hiroyuki
2010-02-19  0:04               ` KAMEZAWA Hiroyuki
2010-02-17 13:29     ` Mel Gorman
2010-02-17 13:29       ` Mel Gorman
2010-02-17 15:45       ` Rik van Riel
2010-02-17 15:45         ` Rik van Riel
2010-02-18 16:58   ` Minchan Kim
2010-02-18 16:58     ` Minchan Kim
2010-02-18 17:34     ` Mel Gorman
2010-02-18 17:34       ` Mel Gorman
2010-02-19  1:21       ` Minchan Kim
2010-02-19  1:21         ` Minchan Kim
2010-02-19 14:33         ` Mel Gorman
2010-02-19 14:33           ` Mel Gorman
2010-02-12 12:00 ` [PATCH 06/12] Add /proc trigger for memory compaction Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-12 18:34   ` Valdis.Kletnieks
2010-02-12 18:38     ` Mel Gorman
2010-02-12 18:38       ` Mel Gorman
2010-02-17 16:30   ` Rik van Riel
2010-02-17 16:30     ` Rik van Riel
2010-02-18 19:51   ` Christoph Lameter
2010-02-18 19:51     ` Christoph Lameter
2010-02-19  1:56   ` Minchan Kim
2010-02-19  1:56     ` Minchan Kim
2010-02-12 12:00 ` [PATCH 07/12] Add /sys trigger for per-node " Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-17 16:30   ` Rik van Riel
2010-02-17 16:30     ` Rik van Riel
2010-02-12 12:00 ` [PATCH 08/12] Direct compact when a high-order allocation fails Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-18  3:57   ` Rik van Riel
2010-02-18  3:57     ` Rik van Riel
2010-02-12 12:00 ` [PATCH 09/12] Do not compact within a preferred zone after a compaction failure Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-18  4:09   ` Rik van Riel
2010-02-18  4:09     ` Rik van Riel
2010-02-12 12:00 ` [PATCH 10/12] mm: Check for an empty VMA list in rmap_walk_anon Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-17 18:22   ` Mel Gorman
2010-02-17 18:22     ` Mel Gorman
2010-02-12 12:00 ` [PATCH 11/12] mm: Take the RCU read lock " Mel Gorman
2010-02-12 12:00   ` Mel Gorman
2010-02-12 12:00 ` [PATCH 12/12] mm: Check the anon_vma is still valid in rmap_walk_anon() Mel Gorman
2010-02-12 12:00   ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1266507477.1709.225.camel@barrios-desktop \
    --to=minchan.kim@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=cl@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.