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 06589C433F5 for ; Wed, 29 Sep 2021 02:11:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9468E6137A for ; Wed, 29 Sep 2021 02:11:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9468E6137A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 139F16B0073; Tue, 28 Sep 2021 22:11:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EA0B6B0074; Tue, 28 Sep 2021 22:11:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1ADA940009; Tue, 28 Sep 2021 22:11:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id DEE916B0073 for ; Tue, 28 Sep 2021 22:11:18 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8DC6322AC6 for ; Wed, 29 Sep 2021 02:11:18 +0000 (UTC) X-FDA: 78638983836.27.3322445 Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by imf24.hostedemail.com (Postfix) with ESMTP id 1DE5FB00009E for ; Wed, 29 Sep 2021 02:11:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1632881476; bh=50W/9JYLvZ7KfcBbBBlSnIl4rE/DXM91XWn/fw+x8B0=; h=X-UI-Sender-Class:Subject:From:To:Cc:Date:In-Reply-To:References; b=CNJrHzkLs2BYk83hIJKh7D6xvlz6ABe1gwUuBgi5xy/GhNScfDYde5cUX8Dm9FuYr uOYDC0trzUVvxfJwCIlnJ9igO2pvlEQjet0xZVU4q16any5zt+xlZrb4fxfYgrIonD c6lKOOpR51if4Sc7FBmKGtarAUmc6k6qh5ZQrUOc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from homer.fritz.box ([185.191.218.45]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHXBj-1mZZwI3mZF-00Da9Y; Wed, 29 Sep 2021 04:11:15 +0200 Message-ID: <3676333711be0277d25a7eb57b8d6c35e8012f5f.camel@gmx.de> Subject: Re: [PATCH] mm/zsmalloc: Replace bit spinlock and get_cpu_var() usage. From: Mike Galbraith To: Andrew Morton , Sebastian Andrzej Siewior Cc: Minchan Kim , linux-mm@kvack.org, Thomas Gleixner Date: Wed, 29 Sep 2021 04:11:14 +0200 In-Reply-To: <20210928154723.1b0577818143734653d9b129@linux-foundation.org> References: <20210923170121.1860133-1-bigeasy@linutronix.de> <20210928084419.mkfu62barwrsvflq@linutronix.de> <20210928154723.1b0577818143734653d9b129@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:W4TZQYsdYwg8TqSjAhxLTV+SIqgBKceo+FosB/wbCrhrmJO7Bz0 dktI6P7ngEZz9p/JT8+/VNRXLeb/Y+gypKnvRtzQIYnD9ah9905qrawjrLBgm3DACkgllD6 1DIu7V1LeDqoPKqLkhQDcueuI/LJh6Mu9RFpN/7RqTRVX8dPiFkRfQL2tWDvkK3o1arlUGC OtOLKW42IEQMDygJwotRw== X-UI-Out-Filterresults: notjunk:1;V03:K0:6h2HjFQJaNg=:1aqDMWhMtjw//ywY3swAAj oPJMEF3wk/iL79MReG/nhZ60C2ab9L8B1sDTI7UI8wFcrDEvqXXKD/MFEuuScikKc66WkoRz1 kLoOk+F2UNlaV22HKhWmxyJ/P4K+QJDUjh3iQUwAhNS5CToeo5Nr7PERKIMRPuJAyjNeMYgbU xYvMmD2KMNjkRya5Zy75DK5RmkdG9v/FKIo6Aa1W/uuuqcdY15Rc57NTpBYTbmjNJdAk5SG9N Q3aTjD20l0cpsna94GCeRU4PB9rAnSZ5ATjSd7HhPlD+gCuflPjSfyv83hEsm5K29X1E0Zn4c wEGQKbDyrnzzuNsejCMofWwKNzycMvYSKLqJoFh48bpwkTpJKAWGCxp1+3ZA1PCzTbOMhkyzt ykZ46Z+8AqOKbhopKG+VoyvYpO8RgrElzT+tG5NsVuNHvmtISjA3wjk6BrcuN7lFVEtP8afja +MYWfeKjT+esd5l5/OemepqXsahmj0rIrZzp6Wh/924hIynXHk/w6a7O02GVdvtLW+LBpgfa1 H9msmlvH/VYo9cDppsRyLN0f1UamRzTjhca7E77Qw5hmHLB7p+PYIb+DG5GOc0gUrQtEGmmxB N5F1OhyHwUnc2fVibRgi2Yx9jYjJLjjZ1GlQ227P2TSRcI970sKxM/LSPz7eVAJ1xKjSRsF6V pvhHkXqH9MzlbXQnDCbP7m0+/ZfqPD+aZpcKyPGoia6QYaaXJoWD5z27dTSVTW0ZeUx/WBX8d o2aQhPxhQfHIs4Ijsh7PIuSfMhX6CHGDMp50lOfzhl/haQheEtUNpVI3yQfjzkLIubnX1Ij4v RSe4SeLAG/CzHPkNzpNYyOTBroy1Xmz5u00vFB8TiJbBpbvQdx+tvHmwrlmkHFisMXd/dL75i bKsQuXi3XU2jtXVNAykX3NFnSFDjitKCFIyw+VFDC0OSpNNOvHlHCrt8MXPTdxyWQkEbQyR33 V8Lfj3I59YvxIZc0K4/BaDja0+6NHSsgCq/3mgKqJ1uZGeX+v6aQo5DydniUy+BuXE23reEvK P2XPmXvoOlkDEfceSKMn0g3lQo811tcqGBwz1bjHdre2aq5HECPF3oOCyzZEDoZX7CyaJ8Uhx uwidjDKrxExIR0= X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1DE5FB00009E X-Stat-Signature: 63m5e58np6s8fag4oyhtkpymm7twxwxq Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=CNJrHzkL; spf=pass (imf24.hostedemail.com: domain of efault@gmx.de designates 212.227.15.18 as permitted sender) smtp.mailfrom=efault@gmx.de; dmarc=pass (policy=none) header.from=gmx.de X-HE-Tag: 1632881477-80582 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 Tue, 2021-09-28 at 15:47 -0700, Andrew Morton wrote: > On Tue, 28 Sep 2021 10:44:19 +0200 Sebastian Andrzej Siewior wrote: > > > From: Mike Galbraith > > > > For efficiency reasons, zsmalloc is using a slim `handle'. The value i= s > > the address of a memory allocation of 4 or 8 bytes depending on the si= ze > > of the long data type. The lowest bit in that allocated memory is used > > as a bit spin lock. > > The usage of the bit spin lock is problematic because with the bit spi= n > > lock held zsmalloc acquires a rwlock_t and spinlock_t which are both > > sleeping locks on PREEMPT_RT and therefore must not be acquired with > > disabled preemption. > > > > Extend the handle to struct zsmalloc_handle which holds the old handle= as > > addr and a spinlock_t which replaces the bit spinlock. Replace all the > > wrapper functions accordingly. > > > > 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. > > > > This survived LTP testing. > > Rather nasty with all the ifdefs and two different locking approaches > to be tested.=C2=A0 What would be the impact of simply switching to the = new > scheme for all configs? > > Which is identical to asking "what is the impact of switching to the new > scheme for PREEMPT_RT"!=C2=A0 Which is I think an important thing for th= e > changelog to address? Good questions both, for which I have no answers. The problematic bit spinlock going away would certainly be preferred if deemed acceptable. I frankly doubt either it or zram would be missed were they to instead be disabled for RT configs. I certainly have no use for it, making it functional was a simple case of boy meets bug, and annoys it to death. -Mike