linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: 'Hugh Dickins' <hugh@veritas.com>,
	"Seth, Rohit" <rohit.seth@intel.com>,
	William Irwin <wli@holomorphy.com>,
	agl@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@osdl.org
Subject: Re: FW: [PATCH 0/3] Demand faulting for huge pages
Date: Mon, 10 Oct 2005 11:32:04 +0200	[thread overview]
Message-ID: <200510101132.05620.ak@suse.de> (raw)
In-Reply-To: <200510100651.j9A6pZg13871@unix-os.sc.intel.com>

On Monday 10 October 2005 08:51, Chen, Kenneth W wrote:

> Demand paging is one aspect of enhancing generality of hugetlb.  Intel
> initially proposed the feature 18 month ago [* see link below] along
> with SGI. Christoph Lameter at SGI scratched that subject Oct 2004.
> And now, Adam at IBM attempts it again.  There is a growing need to
> make hugetlb easier to use, more transparency in using hugetlb pages
> etc.  All requires hugetlb code to be more generalized, instead of
> reducing functionality.

It's also badly needed to make hugetlbfs NUMA policy aware. mbind
requires allocation on demand, because it runs after mmap and
cannot fix up the policy when the pages are already allocated.

> Granted, the patch I posted on expanding ftruncate will be replaced
> once demand paging goes in.  I wanted to demonstrate that it is a
> feature we should implement, instead of cutting back more on current
> thin functionality in hugetlbfs. (with demand paging, expanding
> ftruncate should be really easy and clean, instead of "peculiar
> semantics" all because of prefaulting).

I would like to have it. I remember hating to implement extending 
truncate by hand when I did the test programs for the hugetlbfs numa policy.

-Andi

--
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:[~2005-10-10  9:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <B05667366EE6204181EABE9C1B1C0EB5086AF0DF@scsmsx401.amr.corp.intel.com>
2005-10-07 21:28 ` Rohit Seth
2005-10-08  7:57   ` Chen, Kenneth W
2005-10-09 12:27     ` Hugh Dickins
2005-10-10  6:51       ` Chen, Kenneth W
2005-10-10  9:32         ` Andi Kleen [this message]
2005-10-10 16:17       ` Adam Litke
2005-10-11  3:10         ` Andrew Morton

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=200510101132.05620.ak@suse.de \
    --to=ak@suse.de \
    --cc=agl@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rohit.seth@intel.com \
    --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