[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171024081232.6to62flr7h3qgxvv@dhcp22.suse.cz>
Date: Tue, 24 Oct 2017 10:12:32 +0200
From: Michal Hocko <mhocko@...nel.org>
To: "C.Wehrmeyer" <c.wehrmeyer@....de>
Cc: Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: PROBLEM: Remapping hugepages mappings causes kernel to return
EINVAL
On Tue 24-10-17 09:41:46, C.Wehrmeyer wrote:
[...]
> 1. Provide mmap with some sort of flag (which would be redundant IMHO) in
> order to churn out properly aligned pages (not transparent, but the current
> MAP_HUGETLB flag isn't either).
You can easily implement such a thing in userspace. In fact glibc has
already done that for you.
> 2. Based on THP enabling status always churn out properly aligned pages, and
> just failsafe to smaller pages if hugepages couldn't be allocated (truly
> transparent).
> 3. Map in memory, then tell madvise to make as many hugepages out of it as
> possible while still keeping the initial mapping (not transparent, and not
> sure Linux can actually do that).
I think there is still some confusion here. Kernel will try to fault in
THP pages on properly aligned addresses. So if you create a larger
mapping than the THP size then you will get a THP (assuming the memory
is not fragmented). It is just the unaligned addresses will get regular
pages.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists