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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 2C04DC433DB for ; Tue, 26 Jan 2021 19:10:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE05A22A84 for ; Tue, 26 Jan 2021 19:10:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE05A22A84 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 16ED08D0106; Tue, 26 Jan 2021 14:10:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F86E8D00F8; Tue, 26 Jan 2021 14:10:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F02A08D0106; Tue, 26 Jan 2021 14:10:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id D21418D00F8 for ; Tue, 26 Jan 2021 14:10:24 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8CEA31EE6 for ; Tue, 26 Jan 2021 19:10:24 +0000 (UTC) X-FDA: 77748867168.20.arm31_3406ef927590 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 50107180C061E for ; Tue, 26 Jan 2021 19:10:24 +0000 (UTC) X-HE-Tag: arm31_3406ef927590 X-Filterd-Recvd-Size: 6931 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 Jan 2021 19:10:23 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id b8so10280592plh.12 for ; Tue, 26 Jan 2021 11:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/pySoVPj6x2FMVMDC3PwlkUp7Fwc7oRZb5nCpTSbyxQ=; b=Kno6Uq1KChTjup+cYxZsCvQQHrWKR+TvGJmKwMtOI7jpjF3oTBKfkjxna4GAaQnzUe PyfN4sriJBZGjz+UGvJ23ap8wPDZNDcbGSW1x0bu386315/oa7rPYe4mOOni01Hu+Mb0 wN9iTOneC4o/FGqSazvRUfiHj4cD9QIPNlv26j7kMA+4vj93pRp+ix8IMpblCuztyp+b L2a5nkRL6tzM3I64JhXq5e53tqETri0b6mAt7wHFGjZteY01SB3Js485e6csvtse6dSX DWdCyPGkqo8hT56y6ZBKNRHRNbhI7L5q+pQbR5mhexFnjPcoZAnlnme/uuKufbZTupV4 nikg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=/pySoVPj6x2FMVMDC3PwlkUp7Fwc7oRZb5nCpTSbyxQ=; b=fr8oGNEYbYtD0dlY1t9bcmy1Er7HCecxLx9KH+7/KcK8MugoplUstLaesMBb6OOJNx 6knWrA2Oh2Af5p+i4uUycSguqhB/e+sYA/4gTtiA3my6Ci1N1D745HGNZACNSUH4K6Dm AoG7QzKpceDgwk7EDyLBRWEpKwNLFcfhRonITJiEAK7wvnnGVF+K9dbuJLp+dctzOmH5 SjZsqg4e2Bto8UaQBoNAzr8InQy0KMvCDZCMPn4lhjEjz+YgFnWXyKXfO99Ke4Xs9hpD 14GDFzE9YG7cDYrSMcKRwzG4PquTmpVJCxnctKNyNFmqKTqyzWD9UaHAG4NKWtQqNgf0 AWRw== X-Gm-Message-State: AOAM530kBKOUBNoRIuj6O5h9lM145Dkfks6y1+8EMpH42Ce8gwvJp8JB FzQA2N9ctDiwhgFl59awHls= X-Google-Smtp-Source: ABdhPJwWecYPRIlieWfot1SXaGDWSpfbRFecAz3my6DVfWYKNjOZ1cQl+qt2qR2hJDfOo2isASG1lQ== X-Received: by 2002:a17:902:9049:b029:da:efd6:4c12 with SMTP id w9-20020a1709029049b02900daefd64c12mr7512150plz.12.1611688222672; Tue, 26 Jan 2021 11:10:22 -0800 (PST) Received: from google.com ([2620:15c:211:201:9dd5:b47b:bb84:dede]) by smtp.gmail.com with ESMTPSA id v2sm18941836pgs.50.2021.01.26.11.10.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jan 2021 11:10:21 -0800 (PST) Date: Tue, 26 Jan 2021 11:10:18 -0800 From: Minchan Kim To: Michal Hocko Cc: Andrew Morton , linux-mm , LKML , hyesoo.yu@samsung.com, david@redhat.com, surenb@google.com, pullip.cho@samsung.com, joaodias@google.com, hridya@google.com, john.stultz@linaro.org, sumit.semwal@linaro.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, hch@infradead.org, robh+dt@kernel.org, linaro-mm-sig@lists.linaro.org Subject: Re: [PATCH v4 2/4] mm: failfast mode with __GFP_NORETRY in alloc_contig_range Message-ID: References: <20210121175502.274391-1-minchan@kernel.org> <20210121175502.274391-3-minchan@kernel.org> <20210125131200.GG827@dhcp22.suse.cz> <20210126074449.GA827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210126074449.GA827@dhcp22.suse.cz> 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 Tue, Jan 26, 2021 at 08:44:49AM +0100, Michal Hocko wrote: > On Mon 25-01-21 11:33:36, Minchan Kim wrote: > > On Mon, Jan 25, 2021 at 02:12:00PM +0100, Michal Hocko wrote: > > > On Thu 21-01-21 09:55:00, Minchan Kim wrote: > > > > Contiguous memory allocation can be stalled due to waiting > > > > on page writeback and/or page lock which causes unpredictable > > > > delay. It's a unavoidable cost for the requestor to get *big* > > > > contiguous memory but it's expensive for *small* contiguous > > > > memory(e.g., order-4) because caller could retry the request > > > > in different range where would have easy migratable pages > > > > without stalling. > > > > > > > > This patch introduce __GFP_NORETRY as compaction gfp_mask in > > > > alloc_contig_range so it will fail fast without blocking > > > > when it encounters pages needed waiting. > > > > > > I am not against controling how hard this allocator tries with gfp mask > > > but this changelog is rather void on any data and any user. > > > > > > It is also rather dubious to have retries when then caller says to not > > > retry. > > > > Since max_tries is 1 with ++tries, it shouldn't retry. > > OK, I have missed that. This is a tricky code. ASYNC mode should be > completely orthogonal to the retries count. Those are different things. > Page allocator does an explicit bail out based on __GFP_NORETRY. You > should be doing the same. A concern with __GFP_NOWAIT is regardless of flags passed to cma_alloc, internal implementation of alloc_contig_range inside will use blockable operation. See __alloc_contig_migrate_range. If we go with __GFP_NOWAIT, we should propagate the gfp_mask inside of __alloc_contig_migrate_range to make cma_alloc consistent with alloc_pages. (IIUC, that's what you want - make gfp_mask consistent between cma_alloc and alloc_pages) but I am worry about the direction will make complicate situation since cma invovles migration context as well as target page allocation context. Sometime, the single gfp flag could be trouble to express both contexts all at once. > > > > > > > Also why didn't you consider GFP_NOWAIT semantic for non blocking mode? > > > > GFP_NOWAIT seems to be low(specific) flags rather than the one I want to > > express. Even though I said only page writeback/lock in the description, > > the goal is to avoid costly operations we might find later so such > > "failfast", I thought GFP_NORETRY would be good fit. > > I suspect you are too focused on implementation details here. Think > about the indended semantic. Callers of this functionality will not > think about those (I hope because if they rely on these details then the > whole thing will become unmaintainable because any change would require > an audit of all existing users). All you should be caring about is to > control how expensive the call can be. GFP_NOWAIT is not really low > level from that POV. It gives you a very lightweight non-sleeping > attempt to allocate. GFP_NORETRY will give you potentially sleeping but > an opportunistic-easy-to-fail attempt. And so on. See how that is > absolutely free of any page writeback or any specific locking. With above reason I mentioned, I wanted to express __GFP_NORETRY as "opportunistic-easy-to-fail attempt" to support cma_alloc as "failfast" for migration context. > -- > Michal Hocko > SUSE Labs