From: Andy Whitcroft <apw@shadowen.org>
To: Andrew Morton <akpm@osdl.org>
Cc: "Chen, Kenneth W" <kenneth.w.chen@intel.com>,
'Ray Bryant' <raybry@sgi.com>,
"Martin J. Bligh" <mbligh@aracnet.com>,
linux-kernel@vger.kernel.org, anton@samba.org,
sds@epoch.ncsc.mil, ak@suse.de, lse-tech@lists.sourceforge.net,
linux-ia64@vger.kernel.org
Subject: HUGETLB commit handling.
Date: Thu, 08 Apr 2004 16:35:30 +0000 [thread overview]
Message-ID: <15037082.1081445730@42.150.104.212.access.eclipse.net.uk> (raw)
We have been looking at the HUGETLB page commit issue (offlist) and are
close a final merged patch. However, our testing seems to have thrown up
an inconsistency in interface which we are not sure whether to fix or not.
With normal shm segments we commit the pages we will need at shmget() time.
The real pages being allocated on demand. With hugetlb pages we currently
do not manage commit, but allocate them on map, shmat() in this case. When
we add commit handling it would seem most appropriate to commit the pages
in shmget() as for small page mappings. However, this might seem to change
the semantics slightly, in that if there is insufficient hugepages
available then the failure would come at shmget() and not shmat() time.
I would contend this is the right thing to do, as it makes the semantics of
hugepages match that of the existing small pages. We are looking for a
consensus as this might be construed as a semantic change.
Thoughts.
-apw
next reply other threads:[~2004-04-08 16:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-08 16:35 Andy Whitcroft [this message]
2004-04-08 21:58 ` HUGETLB commit handling Seth, Rohit
2004-04-08 22:47 ` Andrew Morton
2004-04-13 10:20 ` Andy Whitcroft
[not found] <1IKJu-Zn-29@gated-at.bofh.it>
2004-04-08 17:05 ` Andi Kleen
2004-04-08 17:23 ` Ray Bryant
2004-04-08 17:51 ` Andi Kleen
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=15037082.1081445730@42.150.104.212.access.eclipse.net.uk \
--to=apw@shadowen.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mbligh@aracnet.com \
--cc=raybry@sgi.com \
--cc=sds@epoch.ncsc.mil \
/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