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 A3215C433DB for ; Thu, 28 Jan 2021 07:53:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F22FD64DD1 for ; Thu, 28 Jan 2021 07:53:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F22FD64DD1 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 3F52A6B0070; Thu, 28 Jan 2021 02:53:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 37EFC6B0071; Thu, 28 Jan 2021 02:53:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 245126B0072; Thu, 28 Jan 2021 02:53:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 09DF86B0070 for ; Thu, 28 Jan 2021 02:53:29 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BFB9B181AEF31 for ; Thu, 28 Jan 2021 07:53:28 +0000 (UTC) X-FDA: 77754418896.05.wheel85_2c0ffc92759e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id A2E9918001BF8 for ; Thu, 28 Jan 2021 07:53:28 +0000 (UTC) X-HE-Tag: wheel85_2c0ffc92759e X-Filterd-Recvd-Size: 4079 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Jan 2021 07:53:28 +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=1611820406; 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=xSK7HTq3+bwPr5/ZmeHgDam4Owbrz6XJGaTagKZ9+Sc=; b=JBFgrFCavxvgBNIvYnVReaCc/L1j5MxrQZNythF4AUSJ25X5TtF5VN1jumotZkagat0tSo pwk7RC9SU5eAz9zppnc8tAmzpbNjvBDAksxhBTmbk1WJs10RbLoc8ga6FwjNo1cFuEFnEU 8lDAPhWlIxmT0d8GZB5YZZwLPPAeHoc= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id AD9F3AC45; Thu, 28 Jan 2021 07:53:26 +0000 (UTC) Date: Thu, 28 Jan 2021 08:53:25 +0100 From: Michal Hocko To: Minchan Kim 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: 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 Wed 27-01-21 12:42:45, Minchan Kim wrote: > 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. > > Before sending next revision, let me check this part again. > > I want to use __GFP_NORETRY to indicate "opportunistic-easy-to-fail attempt" > and I want to use ASYNC migrate_mode to help the goal. > > Do you see the problem? No, as I've said. This is a normal NORETRY policy. And ASYNC migration is a mere implementation detail you do not have bother your users about. This is the semantic view. From the implementation POV it should be the gfp mask to drive decisions rather than a random (ASYNC) flag to control retries as you did here. -- Michal Hocko SUSE Labs