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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34B58C433EF for ; Mon, 15 Nov 2021 03:57:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 91BB461C32 for ; Mon, 15 Nov 2021 03:57:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 91BB461C32 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id ACD976B007B; Sun, 14 Nov 2021 22:56:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7DB16B007D; Sun, 14 Nov 2021 22:56:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96C0D6B007E; Sun, 14 Nov 2021 22:56:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 8433D6B007B for ; Sun, 14 Nov 2021 22:56:59 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2516F876E6 for ; Mon, 15 Nov 2021 03:56:59 +0000 (UTC) X-FDA: 78809803758.06.CFE1D3C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf06.hostedemail.com (Postfix) with ESMTP id 8930F801A8AE for ; Mon, 15 Nov 2021 03:56:58 +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-out1.suse.de (Postfix) with ESMTPS id D8567218E1; Mon, 15 Nov 2021 03:56:56 +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 imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 060FB13310; Mon, 15 Nov 2021 03:56:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id //d5M4bakWESIwAAMHmgww (envelope-from ); Mon, 15 Nov 2021 03:56:54 +0000 Date: Sun, 14 Nov 2021 19:56:47 -0800 From: Davidlohr Bueso To: Minchan Kim Cc: Andrew Morton , Sergey Senozhatsky , linux-mm , Sebastian Andrzej Siewior , Mike Galbraith , Thomas Gleixner Subject: Re: [PATCH 8/8] zsmalloc: replace get_cpu_var with local_lock Message-ID: <20211115035647.oh3wf6avptlo565k@offworld> Mail-Followup-To: Minchan Kim , Andrew Morton , Sergey Senozhatsky , linux-mm , Sebastian Andrzej Siewior , Mike Galbraith , Thomas Gleixner References: <20211110185433.1981097-1-minchan@kernel.org> <20211110185433.1981097-9-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20211110185433.1981097-9-minchan@kernel.org> User-Agent: NeoMutt/20201120 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8930F801A8AE X-Stat-Signature: oyynfnmqrumk7arnyc7d1gwfaa3ixmpk Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=softfail (imf06.hostedemail.com: 195.135.220.28 is neither permitted nor denied by domain of dave@stgolabs.net) smtp.mailfrom=dave@stgolabs.net X-HE-Tag: 1636948618-390009 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 Wed, 10 Nov 2021, Minchan Kim wrote: >From: Sebastian Andrzej Siewior > >The usage of get_cpu_var() in zs_map_object() is problematic because >it disables preemption and makes it impossible to acquire any sleeping >lock on PREEMPT_RT such as a spinlock_t. >Replace the get_cpu_var() usage with a local_lock_t which is embedded >struct mapping_area. It ensures that the access the struct is >synchronized against all users on the same CPU. On a similar note (and sorry for hijacking the thread) I've been looking at the remaining users of get_cpu_light() in a hope to see them upstreamed and removed out-of-tree now that we have local locks. There are six, and afaict, they can be addressed with either using local locks: 1. netif_rx. We can add a local_lock_t to softnet_data which is the pcpu data strucutre used by enqueue_to_backlog(). Then replace both preempt_disable and get_cpu with local_lock(&softnet_data.lock). 2. blk-mq. Such scenarios rely on implicitly disabling preemption to guarantee running __blk_mq_run_hw_queue() on the right CPU. But we can use a local lock for synchronous hw queue runs, thus adding a local_lock_t to struct blk_mq_hw_ctx. 3. raid5. We can add a local_lock_t to struct raid5_percpu. 4. scsi/fcoe. There are 3 things here to consider: tx stats management, fcoe_percpu_s and the exchange manager pool. For the first two adding a local_lock_t to fc_stats and fcoe_percpu_s should do it, but we would have to do a migrate_disable() for pool case in fc_exch_em_alloc() which yes is ugly... pool->lock is already there. ... or flat-out migrate_disabling when the per-CPU data structure already has a spinlock it acquires anyway, which will do the serialization: 5. vmalloc. Since we already have a vmap_block_queue.lock 6. sunrpc. Since we already have a pool->sp_lock. I've got patches for these but perhaps I'm missing a fundamental reason as to why these are still out-of-tree and get_cpu()-light family is still around. For example, direct migrate_disable() calls are frowned upon and could well be unacceptable - albeit it's recent user growth upstream. Thoughts? Thanks, Davidlohr