From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: 'Hugh Dickins' <hugh@veritas.com>
Cc: "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: Sun, 9 Oct 2005 23:51:11 -0700 [thread overview]
Message-ID: <200510100651.j9A6pZg13871@unix-os.sc.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0510091306440.7878@goblin.wat.veritas.com>
Hugh Dickins wrote on Sunday, October 09, 2005 5:27 AM
> We all seem
> to have different agendas for hugetlb. I'm interested in fixing the
> existing bugs with truncation (see -mm), and getting the locking to
> fit with my page_table_lock patches. Prohibiting truncation is an
> attractively easy and efficient way of fixing several such problems.
> Adam is interested in fault on demand, which needs further work if
> truncation is allowed. You and Rohit are interested in enhancing
> the generality of hugetlbfs.
IMO, these three things are not contradictory with each other. They
are orthogonal. Even though maybe we are all touching same lines of
code, in the end, everyone is working toward better and more robust
hugetlb code.
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.
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).
- Ken
[*] http://marc.theaimsgroup.com/?l=linux-ia64&m=108189860401704&w=2
--
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>
next prev parent reply other threads:[~2005-10-10 6:51 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 [this message]
2005-10-10 9:32 ` Andi Kleen
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=200510100651.j9A6pZg13871@unix-os.sc.intel.com \
--to=kenneth.w.chen@intel.com \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=hugh@veritas.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