linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: David Rientjes <rientjes@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/7] Export unusable free space index via /proc/pagetypeinfo
Date: Mon, 8 Feb 2010 12:10:48 +0000	[thread overview]
Message-ID: <20100208121048.GB23680@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.2.00.1002051336360.12934@chino.kir.corp.google.com>

On Fri, Feb 05, 2010 at 01:40:21PM -0800, David Rientjes wrote:
> On Fri, 5 Feb 2010, Mel Gorman wrote:
> 
> > > > +	/*
> > > > +	 * Index should be a value between 0 and 1. Return a value to 3
> > > > +	 * decimal places.
> > > > +	 *
> > > > +	 * 0 => no fragmentation
> > > > +	 * 1 => high fragmentation
> > > > +	 */
> > > > +	return ((info->free_pages - (info->free_blocks_suitable << order)) * 1000) / info->free_pages;
> > > > +
> > > 
> > > This value is only for userspace consumption via /proc/pagetypeinfo, so 
> > > I'm wondering why it needs to be exported as an index.  Other than a loss 
> > > of precision, wouldn't this be easier to understand (especially when 
> > > coupled with the free page counts already exported) if it were multipled 
> > > by 100 rather than 1000 and shown as a percent of _usable_ free memory at 
> > > each order? 
> > 
> > I find it easier to understand either way, but that's hardly a surprise.
> > The 1000 is because of the loss of precision. I can make it a 100 but I
> > don't think it makes much of a difference.
> > 
> 
> This suggestion was coupled with the subsequent note that there is no 
> documentation of what "unusuable free space index" is, except by the 
> implementation itself.  Since the value isn't used by the kernel,  I think 
> exporting the value as a percent would be easier understood by the user 
> without looking up the semantics.  I don't have strong feelings either 
> way, however.
> 

I'm writing documentation. I'm keeping with the 1000 value because a) I
like the precision and b) the fragmentation index is not related to
percentages and I think having one as a percentage and the other as an
index would cause confusion. Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

  reply	other threads:[~2010-02-08 12:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-06 16:26 [RFC-PATCH 0/7] Memory Compaction v1 Mel Gorman
2010-01-06 16:26 ` [PATCH 1/7] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA Mel Gorman
2010-01-07 21:46   ` David Rientjes
2010-01-07 22:04     ` Christoph Lameter
2010-01-19 13:00     ` Mel Gorman
2010-01-06 16:26 ` [PATCH 2/7] Export unusable free space index via /proc/pagetypeinfo Mel Gorman
2010-01-06 17:10   ` Adam Litke
2010-01-06 17:29     ` Mel Gorman
2010-01-06 23:21   ` Tim Pepper
2010-01-28 22:27   ` David Rientjes
2010-02-05 10:23     ` Mel Gorman
2010-02-05 21:40       ` David Rientjes
2010-02-08 12:10         ` Mel Gorman [this message]
2010-01-06 16:26 ` [PATCH 3/7] Export fragmentation " Mel Gorman
2010-01-06 16:26 ` [PATCH 4/7] Memory compaction core Mel Gorman
2010-01-06 17:50   ` Mel Gorman
2010-01-06 18:22     ` Mel Gorman
2010-01-06 21:37   ` Andi Kleen
2010-01-06 22:07     ` Mel Gorman
2010-01-06 16:26 ` [PATCH 5/7] Add /proc trigger for memory compaction Mel Gorman
2010-01-07 22:00   ` David Rientjes
2010-01-13 23:23     ` David Rientjes
2010-01-20  9:48       ` Mel Gorman
2010-01-20  9:48     ` Mel Gorman
2010-01-20 18:12       ` Christoph Lameter
2010-01-20 20:53         ` Mel Gorman
2010-01-20 20:48       ` David Rientjes
2010-01-21 14:09         ` Mel Gorman
2010-01-21 23:34           ` David Rientjes
2010-01-06 16:26 ` [PATCH 6/7] Direct compact when a high-order allocation fails Mel Gorman
2010-01-06 16:26 ` [PATCH 7/7] Do not compact within a preferred zone after a compaction failure Mel Gorman
2010-01-13 23:28   ` David Rientjes
2010-01-20  9:51     ` Mel Gorman
2010-01-21  3:12 ` [RFC-PATCH 0/7] Memory Compaction v1 KOSAKI Motohiro
2010-01-21 10:11   ` Mel Gorman
2010-01-22  0:16     ` KOSAKI Motohiro

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=20100208121048.GB23680@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=aarcange@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).