From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CF6FC10F14 for ; Tue, 15 Oct 2019 14:05:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 42E6020854 for ; Tue, 15 Oct 2019 14:05:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42E6020854 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EBA438E0009; Tue, 15 Oct 2019 10:05:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6A9C8E0001; Tue, 15 Oct 2019 10:05:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7FD58E0009; Tue, 15 Oct 2019 10:05:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id B4BFB8E0001 for ; Tue, 15 Oct 2019 10:05:11 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 473E36130 for ; Tue, 15 Oct 2019 14:05:11 +0000 (UTC) X-FDA: 76046190822.12.bomb05_2d3ac41888348 X-HE-Tag: bomb05_2d3ac41888348 X-Filterd-Recvd-Size: 2260 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Oct 2019 14:05:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 88132AFBB; Tue, 15 Oct 2019 14:05:09 +0000 (UTC) Date: Tue, 15 Oct 2019 16:05:08 +0200 From: Michal Hocko To: "Guilherme G. Piccoli" Cc: Guilherme Piccoli , Qian Cai , linux-mm@kvack.org, mike.kravetz@oracle.com, linux-kernel@vger.kernel.org, Jay Vosburgh , "Guilherme G. Piccoli" Subject: Re: [PATCH] hugetlb: Add nohugepages parameter to prevent hugepages creation Message-ID: <20191015140508.GJ317@dhcp22.suse.cz> References: <4641B95A-6DD8-4E8A-AD53-06E7B72D956C@lca.pw> <20191015121803.GB24932@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote: > On 10/15/19 9:18 AM, Michal Hocko wrote: > > I do agree with Qian Cai here. Kdump kernel requires a very tailored > > environment considering it is running in a very restricted > > configuration. The hugetlb pre-allocation sounds like a tooling problem > > and should be fixed at that layer. > > > > Hi Michal, thanks for your response. Can you suggest me a current way of > preventing hugepages for being created, using userspace? The goal for this > patch is exactly this, introduce such a way. Simply restrict the environment to not allocate any hugepages? Kdump already controls the kernel command line and it also starts only a very minimal subset of services. So who is allocating those hugepages? sysctls should be already excluded by default as Qian mentioned. -- Michal Hocko SUSE Labs