[<prev] [next>] [day] [month] [year] [list]
Message-ID: <552ED2B8.3060308@oracle.com>
Date: Wed, 15 Apr 2015 14:06:00 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: linux-mm@...ck.org, linux-kernel <linux-kernel@...r.kernel.org>
CC: Dave Hansen <dave.hansen@...el.com>,
David Rientjes <rientjes@...gle.com>,
Davide Libenzi <davidel@...ilserver.org>,
Eric B Munson <emunson@...mai.com>,
Hugh Dickins <hughd@...gle.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Vlastimil Babka <vbabka@...e.cz>
Subject: hugetlbfs alignment requirements conflicting with documentation
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists