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 EB526CCA479 for ; Mon, 4 Jul 2022 14:40:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79B5B6B0072; Mon, 4 Jul 2022 10:40:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74B886B0073; Mon, 4 Jul 2022 10:40:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6131B6B0074; Mon, 4 Jul 2022 10:40:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4E44D6B0072 for ; Mon, 4 Jul 2022 10:40:00 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 24C07805BB for ; Mon, 4 Jul 2022 14:40:00 +0000 (UTC) X-FDA: 79649676960.20.D4C88E2 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id 8AE7914000D for ; Mon, 4 Jul 2022 14:39:59 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 2908E20272; Mon, 4 Jul 2022 14:39:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1656945598; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CAxWQ9NhdZjwnh3NBb4lAHsXOxATS56cntUW47YLCw4=; b=XlNRsO3JE0e31wuW7i0y+kyLIl3aF4F8Hw0mMlFekSq5j8mG5sh26unraX71Gu7gO+cyZd 3ETbCuXfMMSQrMbmPRjeoZJyCzm9NGynAnjPSJOVudI6kdvomGcNCZjOSkHMj82TtPrTEH 85gCTQrdyv63BXe4kBYa9YmUkK8+CYs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1656945598; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CAxWQ9NhdZjwnh3NBb4lAHsXOxATS56cntUW47YLCw4=; b=x8DzM+Crawj0He+ND5c4l9U5IZ+8hUWLjghX/JLrYwk08izvbBOyb1wxHTsIX7FB2MhPEy kkyO+zVdzCwUweCg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 033C613451; Mon, 4 Jul 2022 14:39:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +2IDAL77wmJ0ZAAAMHmgww (envelope-from ); Mon, 04 Jul 2022 14:39:57 +0000 Message-ID: Date: Mon, 4 Jul 2022 16:39:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 7/7] mm/page_alloc: Replace local_lock with normal spinlock Content-Language: en-US To: Mel Gorman , Andrew Morton Cc: Nicolas Saenz Julienne , Marcelo Tosatti , Michal Hocko , Hugh Dickins , Yu Zhao , Marek Szyprowski , LKML , Linux-MM References: <20220624125423.6126-1-mgorman@techsingularity.net> <20220624125423.6126-8-mgorman@techsingularity.net> From: Vlastimil Babka In-Reply-To: <20220624125423.6126-8-mgorman@techsingularity.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656945599; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CAxWQ9NhdZjwnh3NBb4lAHsXOxATS56cntUW47YLCw4=; b=j/StkGqJurmN0kYsmJHbu+Gr/FFkSmKwoGJEQdKW0NV+Bjshq1Oa+6NHxnmZBD1vqk+z9b uLSHThDa2df74FZTSQWmSajUhqCZ2Xay26aqzNN0NRB7FQv3JwFJ96LI+RPqRvk3uJTG4S P+bsaXGhkKrHq3fgOsAoTRm5c/16vMw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XlNRsO3J; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=x8DzM+Cr; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656945599; a=rsa-sha256; cv=none; b=E0z/V5tn8yUZwkLd4n+7XXRjgasIMe5Ndotg6AKCsR7LB/EgDONmA9A8cIRZuORJOMCNMA Su0248IRfDT2PQdtwTs1SDCtSLDQtNyoMPh2wKskNl3s1hecpa1BuiDMOfLnVceGp2L4fg Z1Fi3vvrT3M5+tFDPmRMljyyYCnD2KU= X-Stat-Signature: romsn7uooh7pk6brifnhwnmzwymixbqp X-Rspamd-Queue-Id: 8AE7914000D Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=XlNRsO3J; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=x8DzM+Cr; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1656945599-880509 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 6/24/22 14:54, 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 Acked-by: Vlastimil Babka -fix looks OK too