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.2 required=3.0 tests=BAYES_00, 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 CD7ECC433B4 for ; Mon, 12 Apr 2021 11:56:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E69561287 for ; Mon, 12 Apr 2021 11:56:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E69561287 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 540A66B0036; Mon, 12 Apr 2021 07:56:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F0DD6B006C; Mon, 12 Apr 2021 07:56:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9AA6B006E; Mon, 12 Apr 2021 07:56:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 231A56B0036 for ; Mon, 12 Apr 2021 07:56:16 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DA30C824805A for ; Mon, 12 Apr 2021 11:56:15 +0000 (UTC) X-FDA: 78023561910.07.2A97DCE Received: from outbound-smtp35.blacknight.com (outbound-smtp35.blacknight.com [46.22.139.218]) by imf12.hostedemail.com (Postfix) with ESMTP id 7BB44F2 for ; Mon, 12 Apr 2021 11:56:10 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp35.blacknight.com (Postfix) with ESMTPS id EFE381F88 for ; Mon, 12 Apr 2021 12:56:13 +0100 (IST) Received: (qmail 16475 invoked from network); 12 Apr 2021 11:56:13 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 12 Apr 2021 11:56:13 -0000 Date: Mon, 12 Apr 2021 12:56:12 +0100 From: Mel Gorman To: Peter Zijlstra Cc: Linux-MM , Linux-RT-Users , LKML , Chuck Lever , Jesper Dangaard Brouer , Matthew Wilcox , Thomas Gleixner , Ingo Molnar , Michal Hocko , Oscar Salvador Subject: Re: [PATCH 02/11] mm/page_alloc: Convert per-cpu list protection to local_lock Message-ID: <20210412115612.GX3697@techsingularity.net> References: <20210407202423.16022-1-mgorman@techsingularity.net> <20210407202423.16022-3-mgorman@techsingularity.net> <20210408174244.GG3697@techsingularity.net> <20210409075939.GJ3697@techsingularity.net> <20210409133256.GN3697@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7BB44F2 X-Stat-Signature: m6xu7urtrt9gmda5mkzbwe4j61in85zr Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=outbound-smtp35.blacknight.com; client-ip=46.22.139.218 X-HE-DKIM-Result: none/none X-HE-Tag: 1618228570-675578 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 Fri, Apr 09, 2021 at 08:55:39PM +0200, Peter Zijlstra wrote: > On Fri, Apr 09, 2021 at 02:32:56PM +0100, Mel Gorman wrote: > > That said, there are some curious users already. > > fs/squashfs/decompressor_multi_percpu.c looks like it always uses the > > local_lock in CPU 0's per-cpu structure instead of stabilising a per-cpu > > pointer. > > I'm not sure how you read that. > > You're talking about this: > > local_lock(&msblk->stream->lock); > > right? Note that msblk->stream is a per-cpu pointer, so > &msblk->stream->lock is that same per-cpu pointer with an offset on. > > The whole think relies on: > > &per_cpu_ptr(msblk->stream, cpu)->lock == per_cpu_ptr(&msblk->stream->lock, cpu) > > Which is true because the lhs: > > (local_lock_t *)((msblk->stream + per_cpu_offset(cpu)) + offsetof(struct squashfs_stream, lock)) > > and the rhs: > > (local_lock_t *)((msblk->stream + offsetof(struct squashfs_stream, lock)) + per_cpu_offset(cpu)) > > are identical, because addition is associative. > Ok, I think I see and understand now, I didn't follow far enough down into the macro magic and missed this observation so thanks for your patience. The page allocator still incurs a double lookup of the per cpu offsets but it should work for both the current local_lock_irq implementation and the one in preempt-rt because the task will be pinned to the CPU by either preempt_disable, migrate_disable or IRQ disable depending on the local_lock implementation and kernel configuration. I'll update the changelog and comment accordingly. I'll decide later whether to leave it or move the location of the lock at the end of the series. If the patch is added, it'll either incur the double lookup (not that expensive, might be optimised by the compiler) or come up with a helper that takes the lock and returns the per-cpu structure. The double lookup probably makes more sense initially because there are multiple potential users of a helper that says "pin to CPU, lookup, lock and return a per-cpu structure" for both IRQ-safe and IRQ-unsafe variants with the associated expansion of the local_lock API. It might be better to introduce such a helper with multiple users converted at the same time and there are other local_lock users in preempt-rt that could do with upstreaming first. > > drivers/block/zram/zcomp.c appears to do the same although for > > at least one of the zcomp_stream_get() callers, the CPU is pinned for > > other reasons (bit spin lock held). I think it happens to work anyway > > but it's weird and I'm not a fan. > > Same thing. Yep. -- Mel Gorman SUSE Labs