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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 2704BC64E8A for ; Mon, 30 Nov 2020 10:01:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 685D7207BC for ; Mon, 30 Nov 2020 10:00:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="Qn7UPyCg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 685D7207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7F0518D0002; Mon, 30 Nov 2020 05:00:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A1628D0001; Mon, 30 Nov 2020 05:00:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B8658D0002; Mon, 30 Nov 2020 05:00:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id 53C458D0001 for ; Mon, 30 Nov 2020 05:00:57 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 113221100B for ; Mon, 30 Nov 2020 10:00:57 +0000 (UTC) X-FDA: 77540640954.04.look92_50139ea273a1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 80FA5800CE68 for ; Mon, 30 Nov 2020 10:00:56 +0000 (UTC) X-HE-Tag: look92_50139ea273a1 X-Filterd-Recvd-Size: 3528 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 30 Nov 2020 10:00:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1606730454; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K9QLAqcKegNHZ4enxhyxhkwws9hmf//rDueloPUrspE=; b=Qn7UPyCgUNImi1+ilkAUxok8xel0jXaNJWqPi7lVT1fidlp00do2xwiZ3xUt75SXL71fnH VJtyoGDZvZ8PlDU3nCk8pvfZjhZ/uXUe8NHLFTsZ/gBIabJ2VNr9j5+VCdSI4C/skirh9l wsfC/ewhUMXTtl8mj4Owsdvss+Yi/YM= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B3DD4ABD2; Mon, 30 Nov 2020 10:00:54 +0000 (UTC) Date: Mon, 30 Nov 2020 11:00:53 +0100 From: Michal Hocko To: Rik van Riel Cc: hughd@google.com, xuyu@linux.alibaba.com, akpm@linux-foundation.org, mgorman@suse.de, aarcange@redhat.com, willy@infradead.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, vbabka@suse.cz Subject: Re: [PATCH 2/3] mm,thp,shm: limit gfp mask to no more than specified Message-ID: <20201130100053.GD17338@dhcp22.suse.cz> References: <20201124194925.623931-1-riel@surriel.com> <20201124194925.623931-3-riel@surriel.com> <20201126134034.GI31550@dhcp22.suse.cz> <920c627330f3c7d295ab58edd1b62f28fdbd14bc.camel@surriel.com> <20201127075214.GK31550@dhcp22.suse.cz> <1f089a155d7501fb156da34744d282ae1f3d02f7.camel@surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f089a155d7501fb156da34744d282ae1f3d02f7.camel@surriel.com> 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 Fri 27-11-20 14:03:39, Rik van Riel wrote: > On Fri, 2020-11-27 at 08:52 +0100, Michal Hocko wrote: > > On Thu 26-11-20 13:04:14, Rik van Riel wrote: > > > > > > I would be more than happy to implement things differently, > > > but I am not sure what alternative you are suggesting. > > > > Simply do not alter gfp flags? Or warn in some cases of a serious > > mismatch. > > E.g. GFP_ZONEMASK mismatch because there are already GFP_KERNEL users > > of > > shmem. > > Not altering the gfp flags is not really an option, > because that would leads to attempting to allocate THPs > with GFP_HIGHUSER, which is what is used to allocate > regular tmpfs pages. Right but that is a completely different reason to alter the mask and it would be really great to know whether this is a theoretical concern or those users simply do not ever use THPs. Btw. should they be using THPs even if they opt themselves into GFP_KERNEL restriction? > If the THP configuration in sysfs says we should > not > be doing compaction/reclaim from THP allocations, we > should obey that configuration setting, and use a > gfp_flags that results in no compaction/reclaim being done. Yes, I agree with that. The thing I disagree with is that you try to mix how hard to try also from the shmem users which are not really THP aware and they merely want to control how hard to try to order-0 pages. Or more precisely whether to invoke OOM killer before doing their fallback. So your patch adds a very subtle behavior that would be really hard to maintain long term because the way how hart to compact is completely detached from users who use the gfp mask. -- Michal Hocko SUSE Labs