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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8C8CC43334 for ; Tue, 21 Jun 2022 09:26:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AA156B0072; Tue, 21 Jun 2022 05:26:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55A4C6B0073; Tue, 21 Jun 2022 05:26:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 423036B0074; Tue, 21 Jun 2022 05:26:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 33AA56B0072 for ; Tue, 21 Jun 2022 05:26:37 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 0C82D80F39 for ; Tue, 21 Jun 2022 09:26:37 +0000 (UTC) X-FDA: 79601712834.12.5451B91 Received: from outbound-smtp31.blacknight.com (outbound-smtp31.blacknight.com [81.17.249.62]) by imf08.hostedemail.com (Postfix) with ESMTP id 780FD1600AD for ; Tue, 21 Jun 2022 09:26:36 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp31.blacknight.com (Postfix) with ESMTPS id 4C1C4C0CC4 for ; Tue, 21 Jun 2022 10:26:35 +0100 (IST) Received: (qmail 8435 invoked from network); 21 Jun 2022 09:26:35 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 21 Jun 2022 09:26:35 -0000 Date: Tue, 21 Jun 2022 10:26:33 +0100 From: Mel Gorman To: Vlastimil Babka Cc: Andrew Morton , Nicolas Saenz Julienne , Marcelo Tosatti , Michal Hocko , Hugh Dickins , LKML , Linux-MM Subject: Re: [PATCH 7/7] mm/page_alloc: Replace local_lock with normal spinlock Message-ID: <20220621092633.GD15453@techsingularity.net> References: <20220613125622.18628-1-mgorman@techsingularity.net> <20220613125622.18628-8-mgorman@techsingularity.net> <43033655-2e78-621b-cc76-c3dc53024d00@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <43033655-2e78-621b-cc76-c3dc53024d00@suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655803596; a=rsa-sha256; cv=none; b=KfiPkvnWeGk5DeDwxKYjSE9kq8uJoMaR+PHfCWfoHgDSob/fEYsnpo8AGbexGJlbBB0cGK miZE8jg5N+mT59YM2rKk3hXnucHI+QIX7Rjs1t0wwBX0cikIbBBZAbbpa/qMAK98Cl6N8o s9SH7nY05oDxo4k5rAirX4tK5QKSRLY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655803596; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wsVn7I6RwJ48v+MGTrfd3TyeqicOcGeqbxERFTiCF5w=; b=iEOPOqKqVDpzKNGPY9SWfHLQVcrl8z69V3j7W+QRRPFDMR03xY5NtvdPh5Zx3rXFMeiXew wD80RbkqbV1taaX46ewJ15aPTbdZSHG5jrzrNsRGFL5aV7KkfAX2kRq4/Ql9cDsJhm44eP TQgfz64R8KJ06PeJ/iZ28zIbvFafY1w= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.62 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.62 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 780FD1600AD X-Stat-Signature: wyw5tir4cppzymgpazczbxqz8swpwmp8 X-HE-Tag: 1655803596-124351 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 Thu, Jun 16, 2022 at 07:01:53PM +0200, Vlastimil Babka wrote: > On 6/13/22 14:56, Mel Gorman wrote: > > struct per_cpu_pages is no longer strictly local as PCP lists can be > > drained remotely using a lock for protection. While the use of local_lock > > works, it goes against the intent of local_lock which is for "pure > > CPU local concurrency control mechanisms and not suited for inter-CPU > > concurrency control" (Documentation/locking/locktypes.rst) > > > > local_lock protects against migration between when the percpu pointer is > > accessed and the pcp->lock acquired. The lock acquisition is a preemption > > point so in the worst case, a task could migrate to another NUMA node > > and accidentally allocate remote memory. The main requirement is to pin > > the task to a CPU that is suitable for PREEMPT_RT and !PREEMPT_RT. > > > > Replace local_lock with helpers that pin a task to a CPU, lookup the > > per-cpu structure and acquire the embedded lock. It's similar to local_lock > > without breaking the intent behind the API. It is not a complete API > > as only the parts needed for PCP-alloc are implemented but in theory, > > the generic helpers could be promoted to a general API if there was > > demand for an embedded lock within a per-cpu struct with a guarantee > > that the per-cpu structure locked matches the running CPU and cannot use > > get_cpu_var due to RT concerns. PCP requires these semantics to avoid > > accidentally allocating remote memory. > > > > Signed-off-by: Mel Gorman > > ... > > > @@ -3367,30 +3429,17 @@ static int nr_pcp_high(struct per_cpu_pages *pcp, struct zone *zone, > > return min(READ_ONCE(pcp->batch) << 2, high); > > } > > > > -/* Returns true if the page was committed to the per-cpu list. */ > > -static bool free_unref_page_commit(struct page *page, int migratetype, > > - unsigned int order, bool locked) > > +static void free_unref_page_commit(struct per_cpu_pages *pcp, struct zone *zone, > > + struct page *page, int migratetype, > > + unsigned int order) > > Hmm given this drops the "bool locked" and bool return value again, my > suggestion for patch 5/7 would result in less churn as those woudn't need to > be introduced? > It would. I considered doing exactly that but I didn't want to drop the reviewed-bys and tested-bys and the change was significant enough to do that. As multiple fixes are needed, I'll do that. > ... > > > @@ -3794,19 +3805,29 @@ static struct page *rmqueue_pcplist(struct zone *preferred_zone, > > struct list_head *list; > > struct page *page; > > unsigned long flags; > > + unsigned long __maybe_unused UP_flags; > > > > - local_lock_irqsave(&pagesets.lock, flags); > > + /* > > + * spin_trylock_irqsave is not necessary right now as it'll only be > > + * true when contending with a remote drain. It's in place as a > > + * preparation step before converting pcp locking to spin_trylock > > + * to protect against IRQ reentry. > > + */ > > + pcp_trylock_prepare(UP_flags); > > + pcp = pcp_spin_trylock_irqsave(zone->per_cpu_pageset, flags); > > + if (!pcp) > > Besides the missing unpin Andrew fixed, I think also this is missing > pcp_trylock_finish(UP_flags); ? > Yes. -- Mel Gorman SUSE Labs