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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E3457C10F27 for ; Mon, 9 Mar 2020 16:12:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AE65C2464B for ; Mon, 9 Mar 2020 16:12:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE65C2464B 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 58EE36B0005; Mon, 9 Mar 2020 12:12:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53FCF6B0006; Mon, 9 Mar 2020 12:12:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4559F6B0007; Mon, 9 Mar 2020 12:12:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2A2A36B0005 for ; Mon, 9 Mar 2020 12:12:34 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id EBDBA180AD811 for ; Mon, 9 Mar 2020 16:12:33 +0000 (UTC) X-FDA: 76576316586.22.pie40_3372f34bc3023 X-HE-Tag: pie40_3372f34bc3023 X-Filterd-Recvd-Size: 5316 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 16:12:33 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id r7so11984759wro.2 for ; Mon, 09 Mar 2020 09:12:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Ns9eVzO0p4o5Bx4eeLESDE82IoXncv33ZlQOlMd3q+E=; b=DPJqycfP2ppxGsxc5LSh86XbX+qdfq/ICBcaA3zvfnU1vB8FekLwVkZNgtTqVU/2HS ywZHsA+fSkVK3YX71GzxmIf+jyug/Y5RGAmzf5m5sIPJoasi/TypTUDuisHMP0KUV4vO geDDft/TNqPlymp4FvFFyAIpXYcSD9W0DpkZ1o/AA2PX3gNJFtG7Q1IV5IVdUcWHEG3T 8hYriOENUeX6alqvirpsOzVq/SxW00JwopmDAP/6z85SKAXfHkr8z5SwF4+sC9UhQJPm nBwTJlb8eBEJc49vTTpCcI/cFCkRXgGXwXSgUIh2egfl3SM+olk33JCVkhERqJAPBTon Fzug== X-Gm-Message-State: ANhLgQ1HiKKWRs1qLt84XvXYt0MpKMnGK8E5n9EVtHC6kZFLxo1RUxkl vem5MNLLQbHp+9zXpN/o4v2Yis+c X-Google-Smtp-Source: ADFU+vtGtkMl72MPjSoG4s8UweB4LM3o4SVaJcSG020HGNIU3RPOAlOTn9cx796UeKN6w4dB0+QhJw== X-Received: by 2002:a5d:514a:: with SMTP id u10mr1799384wrt.360.1583770352235; Mon, 09 Mar 2020 09:12:32 -0700 (PDT) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id u8sm16068166wrn.69.2020.03.09.09.12.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2020 09:12:31 -0700 (PDT) Date: Mon, 9 Mar 2020 17:12:30 +0100 From: Michal Hocko To: Shaju Abraham Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shaju Abraham Subject: Re: [PATCH] mm/vmpressure.c: Include GFP_KERNEL flag to vmpressure Message-ID: <20200309161230.GT8447@dhcp22.suse.cz> References: <20200309113141.167289-1-shaju.abraham@nutanix.com> <20200309115818.GK8447@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 09-03-20 21:02:50, Shaju Abraham wrote: > On Mon, Mar 9, 2020 at 5:28 PM Michal Hocko wrote: > > > On Mon 09-03-20 11:31:41, Shaju Abraham wrote: > > > The VM pressure notification flags have excluded GFP_KERNEL with the > > > reasoning that user land will not be able to take any action in case of > > > kernel memory being low. This is not true always. Consider the case of > > > a user land program managing all the huge memory pages. By including > > > GFP_KERNEL flag whenever the kernel memory is low, pressure notification > > > can be send, and the manager process can split huge pages to satisfy > > kernel > > > memory requirement. > > > > Are you sure about this reasoning? GFP_KERNEL = __GFP_FS | __GFP_IO | > > __GFP_RECLAIM > > Two of the flags mentioned there are already listed so we are talking > > about __GFP_RECLAIM here. Including it here would be a more appropriate > > change than GFP_KERNEL btw. > > > > But still I do not really understand what is the actual problem and how > > is this patch meant to fix it. vmpressure is triggered only from the > > reclaim path which inherently requires to have __GFP_RECLAIM present > > so I fail to see how this can make any change at all. How have you > > tested it? > > > > We have a user space application which waits on memory pressure events. > Upon receiving the event, the user space program will free up huge > pages to make more memory available in the system. This mechanism > works fine if the memory is being consumed by other user space > applications. To test this, we wrote a test program which will > allocate all the memory available in the system using malloc() and > touch the allocated pages. When the free memory level becomes low, > the pressure event is fired and the process gets notified about it . > The same test is repeated with kmalloc() instead of malloc(). A test > kernel module is developed, which will allocate all the available > memory with kmalloc(GFP_KERNEL) flag. The OOM killer gets invoked in > this case. The memory pressure event is not fired. After modifying > the vmpressure.c with the attached patch, the pressure event gets > triggered. Swap is disabled in the system we were testing. Are you sure this is really the case? I am either missing something here or your test might simply be timing specific because GFP_KERNEL & (__GFP_FS | __GFP_IO) = true so I really do not see how the current code could bail out on the test you are patching so that the patch would make any change. The only real difference this patch makes is to trigger events for __GFP_RECLAIM allocations which could be GFP_NOIO. All non-sleepable allocations would wake kswapd and that would in turn reclaim with _GFP_FS | __GFP_IO set so the check doesn't change anything. Am I missing something? -- Michal Hocko SUSE Labs