Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Harrosh, Boaz" <Boaz.Harrosh@netapp.com>
To:     Michal Hocko <mhocko@kernel.org>
CC:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Hugh Dickins <hughd@google.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Matthew Wilcox <willy@infradead.org>,
        Toshi Kani <toshi.kani@hpe.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH] mm: align anon mmap for THP
Thread-Topic: [RFC PATCH] mm: align anon mmap for THP
Thread-Index: AQHUqeoAUFTCAIIvn0CcxSCAmIzKA6WqnMwAgAAaIICABBVXAIAADyeigAAgWwCAAACfyQ==
Date:   Mon, 14 Jan 2019 16:54:02 +0000
Message-ID: <MWHPR06MB289605B9E1B4234674CB87E2EE800@MWHPR06MB2896.namprd06.prod.outlook.com>
References: <20190111201003.19755-1-mike.kravetz@oracle.com>
 <20190111215506.jmp2s5end2vlzhvb@black.fi.intel.com>
 <ebd57b51-117b-4a3d-21d9-fc0287f437d6@oracle.com>
 <20190114135001.w2wpql53zitellus@kshutemo-mobl1>
 <MWHPR06MB2896ACD09C21B2939959C8A8EE800@MWHPR06MB2896.namprd06.prod.outlook.com>,<20190114164004.GL21345@dhcp22.suse.cz>
In-Reply-To: <20190114164004.GL21345@dhcp22.suse.cz>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: netapp.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 492ddb7f-6899-40da-b593-08d67a40e34d
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 16:54:02.7657
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB3293
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Michal Hocko <mhocko@kernel.org> wrote:

<>
> What does prevent you from mapping a larger area and MAP_FIXED,
> PROT_NONE over it to get the protection?

Yes Thanks I will try. That's good.

>> > For THP, I believe, kernel already does The Right Thing=99 for most us=
ers.
>> > User still may want to get speific range as THP (to avoid false sharin=
g or
>> > something).
>>
>> I'm an OK Kernel programmer.  But I was not able to create a HugePage ma=
pping
>> against /dev/shm/ in a reliable way. I think it only worked on Fedora 28=
/29
>> but not on any other distro/version. (MMAP_HUGE)
>
> Are you mixing hugetlb rather than THP?

Probably. I was looking for the easiest way to get my mmap based memory all=
ocations
to be 2M based instead of 4k. to get better IO characteristics across the K=
ernel.
But I kept getting the 4k pointers. (Can't really remember all the things I=
 tried.)

>> We run with our own compiled Kernel on various distros, THP is configure=
d
>> in but mmap against /dev/shm/ never gives me Huge pages. Does it only
>> work with unanimous mmap ? (I think it is mount dependent which is not
>> in the application control)
>
> If you are talking about THP then you have to enable huge pages for the
> mapping AFAIR.

This is exactly what I was looking to achieve but was not able to do. Most =
probably
a stupid omission on my part, but just to show that it is not that trivial =
and strait
out-of-the-man-page way to do it.  (Would love a code snippet if you ever w=
rote one?)

> --
> Michal Hocko
> SUSE Labs

Thanks man
Boaz