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 2E71BC433F5 for ; Mon, 15 Nov 2021 07:28:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A33F661BF5 for ; Mon, 15 Nov 2021 07:28:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A33F661BF5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D648F6B007B; Mon, 15 Nov 2021 02:27:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D14906B007D; Mon, 15 Nov 2021 02:27:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C03496B007E; Mon, 15 Nov 2021 02:27:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id AE8BD6B007B for ; Mon, 15 Nov 2021 02:27:59 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6A01B180CB054 for ; Mon, 15 Nov 2021 07:27:59 +0000 (UTC) X-FDA: 78810335478.30.010D1EF Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf08.hostedemail.com (Postfix) with ESMTP id 699FA30000A9 for ; Mon, 15 Nov 2021 07:27:42 +0000 (UTC) Date: Mon, 15 Nov 2021 08:27:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1636961276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=laWWxiFVz82XIoIgjrN3+oTrsXNkrHP5wOtr9XiPwTg=; b=vahFHNyZ+PtiOHfedmbX3l34WKg4QtchdVAp6JTA62dFHMtXAhe48V2ZyRD+6X3nlgzmid XJsZZH/294IlrIXrfR+KhfwySKmzycw2g3fqL231C6lqFUumtjdqSWe+0ZU0Fdc8VYiUwJ +GQe4IDHgBtwgDuw0/ZOqEE6S6XxHR251uFhEVxjRyXwa+l16hTjNjX1tuSiS0ZRymaTvW H41BtQcfUWW03o1hfOyP4pYyoxVz44maMLsQ9DVRk+YGn0yAbRDNuMh4qtKvOF1utmKkhq DrT6LTx15lxeunAn41v/hlEeG2wT+CDc2azWROX3dnzNf2O0HuJvgIGDRUilgw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1636961276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=laWWxiFVz82XIoIgjrN3+oTrsXNkrHP5wOtr9XiPwTg=; b=njPS5UJFe6uSGcjTqFmKvCV4tqjkCsWSAluYUOdv3j48Oo8S62jtTYS8/lA1/eivNa0+FV yZD94am4mLztOxAQ== From: Sebastian Andrzej Siewior To: Minchan Kim , Andrew Morton , Sergey Senozhatsky , linux-mm , Mike Galbraith , Thomas Gleixner Subject: Re: [PATCH 8/8] zsmalloc: replace get_cpu_var with local_lock Message-ID: <20211115072755.ne2u7qf2k2oyhgwn@linutronix.de> References: <20211110185433.1981097-1-minchan@kernel.org> <20211110185433.1981097-9-minchan@kernel.org> <20211115035647.oh3wf6avptlo565k@offworld> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211115035647.oh3wf6avptlo565k@offworld> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 699FA30000A9 X-Stat-Signature: sjbeceg7phn1fz5zcz5o467wy5m41jnp Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=vahFHNyZ; dkim=pass header.d=linutronix.de header.s=2020e header.b=njPS5UJF; spf=pass (imf08.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1636961262-441461 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 2021-11-14 19:56:47 [-0800], Davidlohr Bueso wrote: > ... 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? I think tglx is looking into this to get it done differently. We had a few more users of get_cpu_light() and we got rid of a few of them. We also had more local_lock() users but we got rid of all but two I think before local_lock() was suggested upstream. >From RT's point of view, get_cpu() and get_cpu_var() leads almost always to trouble. The vmalloc example from above, I don't think there is need for get_cpu() or migrate_disable() or anything at all because the per-CPU data structure itself is locked. The window of possible CPU migration is little so even if it happens, the result is correct. > Thanks, > Davidlohr Sebastian