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=-7.3 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,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 41140C47094 for ; Mon, 7 Jun 2021 10:23:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C76F261164 for ; Mon, 7 Jun 2021 10:23:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C76F261164 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41F1E6B006C; Mon, 7 Jun 2021 06:23:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D0456B006E; Mon, 7 Jun 2021 06:23:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 249CA6B0070; Mon, 7 Jun 2021 06:23:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id E28AB6B006C for ; Mon, 7 Jun 2021 06:23:29 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7569A8249980 for ; Mon, 7 Jun 2021 10:23:29 +0000 (UTC) X-FDA: 78226540938.33.D15FF01 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf12.hostedemail.com (Postfix) with ESMTP id 9B554548 for ; Mon, 7 Jun 2021 10:23:25 +0000 (UTC) Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id ED35E1FDA5; Mon, 7 Jun 2021 10:23:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623061407; 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=3yTVmuXnYhofXBlCbo4IT8YVBm6HcKA8wUzVzSayMos=; b=WzFfC+Wgz7EnMtRD06x4fPqve4Fc88iJSnKAXQcb7EnFrMdFTGTGsiwLavkHVSaRziNCC1 KOEReCqMtueednd86PjVL2UNHo+0u6vS2nSl/yflhcvDpxdE9fMEiT73GFJ8xnGVir6Fn2 jYxAw7LfE8zDDShj3W8EwUpsRxB5Cr8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623061407; 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=3yTVmuXnYhofXBlCbo4IT8YVBm6HcKA8wUzVzSayMos=; b=aoUH1FPnrcaW8PlQgRV9SfiN0ykK3H1waLliOZoBU+6SYnL4wGcL+HKsSSGu59S1RV0PuO jDptSuhc8e/WcgDA== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 4EA63118DD; Mon, 7 Jun 2021 10:23:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623061407; 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=3yTVmuXnYhofXBlCbo4IT8YVBm6HcKA8wUzVzSayMos=; b=WzFfC+Wgz7EnMtRD06x4fPqve4Fc88iJSnKAXQcb7EnFrMdFTGTGsiwLavkHVSaRziNCC1 KOEReCqMtueednd86PjVL2UNHo+0u6vS2nSl/yflhcvDpxdE9fMEiT73GFJ8xnGVir6Fn2 jYxAw7LfE8zDDShj3W8EwUpsRxB5Cr8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623061407; 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=3yTVmuXnYhofXBlCbo4IT8YVBm6HcKA8wUzVzSayMos=; b=aoUH1FPnrcaW8PlQgRV9SfiN0ykK3H1waLliOZoBU+6SYnL4wGcL+HKsSSGu59S1RV0PuO jDptSuhc8e/WcgDA== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id d7jdD5/zvWC2MgAALh3uQQ (envelope-from ); Mon, 07 Jun 2021 10:23:27 +0000 Date: Mon, 7 Jun 2021 12:23:25 +0200 From: Oscar Salvador To: David Hildenbrand Cc: Michal Hocko , Andrew Morton , Dave Hansen , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] mm,page_alloc: Use {get,put}_online_mems() to get stable zone's values Message-ID: <20210607102318.GA12683@linux> References: <20210602091457.17772-1-osalvador@suse.de> <20210602091457.17772-2-osalvador@suse.de> <39473305-6e91-262d-bcc2-76b745a5b14a@redhat.com> <20210604074140.GA25063@linux> <20210607075147.GA10554@linux> <85984701-55ae-dfa5-2a8d-f637051b612d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85984701-55ae-dfa5-2a8d-f637051b612d@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9B554548 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WzFfC+Wg; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=aoUH1FPn; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WzFfC+Wg; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=aoUH1FPn; dmarc=none; spf=pass (imf12.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=osalvador@suse.de X-Stat-Signature: 1nw4emabfzhjz5petdbu5g5hfhy5nxyf X-HE-Tag: 1623061405-569277 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, Jun 07, 2021 at 10:49:01AM +0200, David Hildenbrand wrote: > I'd like to point out that I think the seqlock is not in place to > synchronize with actual growing/shrinking but to get consistent zone ranges > -- like using atomics, but we have two inter-dependent values here. I guess so, at least that's what it should do. But the way it is placed right now is misleading. If we really want to get consistent zone ranges, we should start using zone's seqlock where it matters and that is pretty much all those places that use zone_spans_pfn(). Otherwise there is no way you can be sure the pfn you're checking is within the limits. Moreover, as Michal pointed out early, if we really want to go down that road the locking should be made in the caller evolving the operation, otheriwse things might change once the lock is dropped and you're working with a wrong assumption. I can see arguments for both riping it out and doing it right (but none for the way it is right now). For riping it out, one could say that those races might not be fatal, as usually the pfn you're working with (the one you want to check falls within a certain range) you know is valid, so the worst can happen is you get false positives/negatives and that might or might not be detected further down. How bad are false positive/negatives I guess it depends on the situation, but we already do that right now. The zone_spans_pfn() from page_outside_zone_boundaries() is the only one using locking right now, so well, if we survided this long without locks in other places using zone_spans_pfn() makes one wonder if it is that bad. On the other hand, one could argue that for correctness sake, we should be holding zone's seqlock whenever checking for zone_spans_pfn() to avoid any inconsistency. -- Oscar Salvador SUSE L3