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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 59A95C433E0 for ; Wed, 17 Feb 2021 12:27:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D1B2C64E33 for ; Wed, 17 Feb 2021 12:27:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1B2C64E33 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2997D8D0034; Wed, 17 Feb 2021 07:27:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 249EF8D0019; Wed, 17 Feb 2021 07:27:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 112178D0034; Wed, 17 Feb 2021 07:27:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id EFD298D0019 for ; Wed, 17 Feb 2021 07:27:40 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BCD52180ACF84 for ; Wed, 17 Feb 2021 12:27:40 +0000 (UTC) X-FDA: 77827685880.29.9C26435 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP id 024D0D6 for ; Wed, 17 Feb 2021 12:27:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C95DAB9D4; Wed, 17 Feb 2021 12:27:38 +0000 (UTC) To: Mike Rapoport Cc: Michal Hocko , Mel Gorman , David Hildenbrand , Andrew Morton , Andrea Arcangeli , Baoquan He , Borislav Petkov , Chris Wilson , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , =?UTF-8?Q?=c5=81ukasz_Majczak?= , Mike Rapoport , Qian Cai , "Sarvela, Tomi P" , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, x86@kernel.org References: <20210214180016.GO242749@kernel.org> <20210215212440.GA1307762@kernel.org> <20210216110154.GB1307762@kernel.org> <20210216174914.GD1307762@kernel.org> From: Vlastimil Babka Subject: Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout Message-ID: <0255912b-19af-e8fc-9a04-06a519287716@suse.cz> Date: Wed, 17 Feb 2021 13:27:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210216174914.GD1307762@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 024D0D6 X-Stat-Signature: jnsh77j5idi7fxnnit7jpnuzu5y3gxz5 Received-SPF: none (suse.cz>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1613564856-24913 Content-Transfer-Encoding: quoted-printable 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 2/16/21 6:49 PM, Mike Rapoport wrote: > Hi Vlastimil, >=20 > On Tue, Feb 16, 2021 at 05:39:12PM +0100, Vlastimil Babka wrote: >>=20 >>=20 >> So, Andrea could you please check if this fixes the original >> fast_isolate_around() issue for you? With the VM_BUG_ON not removed, D= EBUG_VM >> enabled, no changes to struct page initialization... >> It relies on pageblock_pfn_to_page as the rest of the compaction code. >=20 > Pardon my ignorance of compaction internals, but does this mean that wi= th > your patch we'll never call set_pfnblock_flags_mask() for a pfn in a ho= le? No it doesn't mean that kind of guarantee. But we will not call it anymor= e (if my patch is correct) from a path which we currently know it's doing that = and triggering the VM_BUG_ON. So that's a targetted fix that matches stable b= ackport criteria. It doesn't contradict your patch as a way to improve mainline, = I still agree it's best long-term if we initialize the struct pages without such surprises. But I also agree with Michal that there's a risk of replacing = one corner case with another and thus we shouldn't do that as a stable fix.