public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: "Ken Chen" <kenchen@google.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	mm-commits@vger.kernel.org, agl@us.ibm.com,
	hermes@gibson.dropbear.id.au, wli@holomorphy.com,
	clameter@sgi.com
Subject: Re: + per-cpuset-hugetlb-accounting-and-administration.patch added to -mm tree
Date: Thu, 3 May 2007 22:12:06 -0700	[thread overview]
Message-ID: <20070503221206.880b1ec8.pj@sgi.com> (raw)
In-Reply-To: <b040c32a0705032149t2a380f82t8145c1d0f8f6736@mail.gmail.com>

Ken wrote:
> If this is odd, do you have any suggestions for alternative?

No, I don't.  Sorry.

It's a touchy problem, and I'm not enough of an expert to know what the
right tradeoffs are in this matter.

I agree with your point that if you realize what's going on, namely
that what cpuset the task reading meminfo is in affects the HugePages
values that are read, then one can use the interface easily enough.

... how about:

 1) don't change the existing HugePages_* values - keep them
    system-wide, and

 2) adding two new values, by such names as:

	Current_Cpuset_HugePages_Total:    0
	Current_Cpuset_HugePages_Free:     0

That's certainly an uglier proposal than yours ;).  But at least it
seems clearer, and doesn't make incompatible changes to what's there.

It does require user level code change to actually benefit from the
new values, whereas your patch sort of sneaks them in, on the assumption
that the majority of reads of these values would really prefer getting
the cpuset relative totals instead.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  parent reply	other threads:[~2007-05-04  5:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200705040104.l4414YFR026322@shell0.pdx.osdl.net>
2007-05-04  1:38 ` + per-cpuset-hugetlb-accounting-and-administration.patch added to -mm tree Paul Jackson
2007-05-04  4:49   ` Ken Chen
2007-05-04  5:03     ` Andrew Morton
2007-05-04  5:58       ` Paul Jackson
2007-05-04  6:13         ` Ken Chen
2007-05-04  7:39           ` Paul Jackson
2007-05-04  5:12     ` Paul Jackson [this message]
2007-05-04  5:35       ` David Rientjes
2007-05-04  6:12         ` Paul Jackson
2007-05-04  6:45   ` Bill Irwin

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=20070503221206.880b1ec8.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=agl@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=hermes@gibson.dropbear.id.au \
    --cc=kenchen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=wli@holomorphy.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