From: Mike Kravetz <mike.kravetz@oracle.com>
To: linux-mm@kvack.org, linux-kernel <linux-kernel@vger.kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
David Rientjes <rientjes@google.com>,
Davide Libenzi <davidel@xmailserver.org>,
Eric B Munson <emunson@akamai.com>,
Hugh Dickins <hughd@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: hugetlbfs alignment requirements conflicting with documentation
Date: Wed, 15 Apr 2015 14:06:00 -0700 [thread overview]
Message-ID: <552ED2B8.3060308@oracle.com> (raw)
A couple of us started looking at adding fallocate() preallocation
and punch hole support to hugetlbfs. The offset and length arguments
to fallocate are in bytes, and the man page is pretty explicit about
what is expected if ranges do not start or end on page boundaries.
Looking at fallocate led me to take a closer look at ftruncate for
hugetlbfs as ideally we would reuse some of that code. I noticed that
ftruncate requires the length parameter to be huge page aligned.
I am pretty sure this was done because hugetlbfs only deals in increments
of huge pages. inode size appears to never be set to anything that
is not a multiple of huge page size. However, the ftruncate man page
does not place too many restrictions on the value of length. And AFICT,
there is no documentation about ftruncate returning EINVAL if length
is not a multiple of huge page size.
So my question is, do we try to support hugetlbfs files that are not a
multiple of huge page size in length? Or, document that hugetlbfs is
'special' when it comes to truncate?
This same question applies to fallocate as the man page also says that
it is possible to set file size to an arbitrary (non huge page size
aligned value).
cc'ing some people from the recent hugetlb munmap alignment thread as
I'm sure they will have an opinion here.
--
Mike Kravetz
--
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:[~2015-04-15 21:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=552ED2B8.3060308@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=dave.hansen@intel.com \
--cc=davidel@xmailserver.org \
--cc=emunson@akamai.com \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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).