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 5E05EC021A0 for ; Thu, 13 Feb 2025 00:52:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E78A66B0085; Wed, 12 Feb 2025 19:52:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E28C86B0088; Wed, 12 Feb 2025 19:52:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D174D280001; Wed, 12 Feb 2025 19:52:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B47186B0085 for ; Wed, 12 Feb 2025 19:52:16 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1F31DC138F for ; Thu, 13 Feb 2025 00:52:16 +0000 (UTC) X-FDA: 83113095072.19.534B772 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf30.hostedemail.com (Postfix) with ESMTP id 42CCD80011 for ; Thu, 13 Feb 2025 00:52:14 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=KS0Wpswj; spf=pass (imf30.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.45 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739407934; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vdYcJdmlJ+mWdpTTpZl2pIT3/xl6BBjB0QV7cYAWqNo=; b=U3bXRmENoM9zSLOtc1tT1FGxFrvaLHDKomJKpMEbk6i6026R0r61BMQOdfygY3kqcF6+t5 uQY8RztWOtJU7EB0cfolkbi3CybNI81YI2zfpM1WuNKU/rqtGzCt/700h9pkKup36sb5bV CSgdd3fT26Ag6zM4Eu0hSTf21NZLInE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=KS0Wpswj; spf=pass (imf30.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.45 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739407934; a=rsa-sha256; cv=none; b=heMnhjTnn25p/SSkZV14LqZD3SwA7/GiDwiGIaoYnHV6umKsQ14GbEIFNB1yjJXVhCLnow uz2UeZmAsSNsK9mfNXVzNe3xLYs9Tb6f8/hvouIVMKwBIK0OxcuYDq2NQR3RIT19sQWTOy qa3K7M3AkMQYozrQbZApBCj2q1b+tio= Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-2fa2c456816so588624a91.1 for ; Wed, 12 Feb 2025 16:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1739407933; x=1740012733; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vdYcJdmlJ+mWdpTTpZl2pIT3/xl6BBjB0QV7cYAWqNo=; b=KS0Wpswj1LnI4IketR9/rkF9Ar27+p1+njPF6m7T+J67vzy+ljEguag8lRoPeO7eSp FTDwnwEg7ZsjJfBeKXgjm4CCNDLDB2qKxryEJATdjufGjCptCFLIKepAwpF5fX5kV/45 C4n1bpluGt5WKAlHs5G4WsdUR+vFRR5MOftZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739407933; x=1740012733; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vdYcJdmlJ+mWdpTTpZl2pIT3/xl6BBjB0QV7cYAWqNo=; b=duE9df0bfFn+MKQUTvM4p5fpz8QoTh8z72zo/dKAnHcWC+j9k9f43qBPGsRyRdhdD3 BOiBnlxcM2nbHPbLB0gyAxDWxeWup0RccQ7JWwl5NVfeiaQRPgOK46Q1vfWMo/U1LeK5 lCOlpqha6RGJdsaWoskhtflRp0HePpcQp4ktlx1pbhb32GiyFQZfKqeKxrYB7sqJYNJ6 eVxs76myrLdxmcanqDMkX8siY6P8WRVjBjNyxsFLeGyhI+BvcKCqJ269BkH3FWsZVQg1 tkpkHtZ8h/nsOOXo3P8rpb8fdXnPwLRTEgk1+Bva8BBi1a/CcLaA4fZppK/wrf8cpfEP ZF1Q== X-Forwarded-Encrypted: i=1; AJvYcCXO2ehafjZMokruXVxu5zYbEeqV4hCqfbTyaAzpCKeKCyf7rMGz1v4fadPddgbrpAnRSuf9qQ38pg==@kvack.org X-Gm-Message-State: AOJu0YzJvNQA4L39KTYSc4aBQbcazs1EQ2xFigpmulXTxeC+QNza6Dp+ k3Hp85hBokZO/kclYZn3gdWATUADQIanrYrWQA8+UR4z9izkXrVOwlQJpMW89A== X-Gm-Gg: ASbGnctlCWax6BPuUrmIGQKu/8kw3cP2/AitafxuFjCeKUYgM9Pf9VwSp6GiI9Pds/a 27YyhAszFFNHGAdMXwMtdOvkRBuG2rHVb19fwkl7m+IEe8Op4o4LJtXKqXa1TsiMaEvFJx7ubTw QCzt7cFRw03k6x8rtca6Gz/ESphEuk//enTfca23+tieKuR98SC7eX5CAMmyz2Ocyhok8h4fwGP Kpa3zyYzgE0PIRaVrzQQlZgtR4vu6bEYDiLG6usj4GyPbBWL7QERk7gYtzmGtjNgOjc21cVIFFI rWwlY6pvM1QuahZZj5k= X-Google-Smtp-Source: AGHT+IGsJSkPhpNC3vMURP6Jrk49JHXtGteNQQY0IjdOo0yQ0F4a/BGPQv4nx/pYEnUi4f0M45E8VA== X-Received: by 2002:a17:90b:180b:b0:2ee:693e:ed7a with SMTP id 98e67ed59e1d1-2fc0f0fedf0mr1719585a91.35.1739407932953; Wed, 12 Feb 2025 16:52:12 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:69f5:6852:451e:8142]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2fbf999b60dsm2100358a91.39.2025.02.12.16.52.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 16:52:12 -0800 (PST) Date: Thu, 13 Feb 2025 09:52:07 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: Sergey Senozhatsky , Yosry Ahmed , Kairui Song , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 01/18] zram: sleepable entry locking Message-ID: References: <20250212063153.179231-1-senozhatsky@chromium.org> <20250212063153.179231-2-senozhatsky@chromium.org> <20250212160830.730a199935e907c2498b28d4@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250212160830.730a199935e907c2498b28d4@linux-foundation.org> X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 42CCD80011 X-Stat-Signature: pfxiaojmjr7o4qftmms4ry4wmcmwekey X-HE-Tag: 1739407934-920726 X-HE-Meta: U2FsdGVkX1+KUflhHTuGdX+J7v1dLD5nxk5wZ5A87K42RqykRy3dFYLQH+cRd3CxauYiN27R21oRW5br5RIWRbp/R+q6tF7NkdbuqX1TMv66LfybTMpBe4o24x1Vqgp0SrLuG9D9OLZbG+aYAchcI99zXbCut7OpuAtD0rbsil2YocXazfzexaSDUk1+JrkzeIRMkvoBVukj/7ErP30exMWlBZj+vLEioJTPuT8hfNamNSU7KxHfGzDdgAT+7sfQg2sB+JQ322Nj/3kODEVUqOUX6giuCkJ7saEMwFRH/f0HWeT1mJOi7EURRSGQtSKBFHze0XSciRM/Ohw68t+i7NjSyuG/PHvJOcbNFnmDbXAjIRHQPpoHp+Wx/avrZOI8+t3cSL867w1AAi0R9vM1NUmvf3T/9T+XgfiBVk3p9PlUU5JJN8/WYnIEpJbbZr8Q48uJy09Zxxdc5vxBKd3xyxIEWbAwwCqzeuygjopeMf39iE9FnwVcEtHE8CtiGmzuEiERep6n7VHaPcfr2gF0bJYnph4tHv05t/0nxZk70EV6NRjgFXIoYHXkiLoVuzEXuKJVoJFbWgW9WBqpDkahUmNC9mNV+PkXsFUtFGAvLXBOWP6Cu8RzAUL7bQNgNsiXfl3lMsrez6DH7jRTKBvsqGPNJH3YikUxTbm3rhXKBO4R2u1JzSmdPSs2chDVrDaA/aasyaS6LoMjcyCqj+5ScMiWBDtzx7n7WxyygFko4RBF7Mdq51hQWna++8vPD1658hh64cT7+YmZTIKlpsN8vYdyw4d2srFWdJQm797Ue6KHwIg4xhK5fPJ6e0Uj5H53w9f1EsplMa2nw7ZkvYXYx+SG+l8Cu5cxQRtkdkwWZAjJaVTp/CfaVXrUJT789co6os/50sd6kyCmuWzGajW8OUGKyw//f4ezgfRBHVq9JlOcY0hL1rA3ttZ4oRkuBp8oDoTp/rNCPB7PRvrhUAa YfdGy5Fd SjAY3rCMICqHRE/0Dn+BGs+HtNiknSQjW16mNmNVNdv3H++8IHey3EJfb5i2ZSCcDf4JWAe5IiFf/Jv7mleNj28pvpFTz0gXnqalV2Bf9sADnbHP/1RQKIo1lmDroUrWvgz+DhZwu1ukXpH7oH0sgbDzPmC9Jyp0dlVTlYKHaD6XJoZ1I4aUTaSeTSE6ikrPaONQJtYv9GuCEclF5sr6+FEd3tkFmXFRWF8Qt8r0iDqmBwLWOAAf8n5SgDQnW1xJ57tl3+IfT2bTIrVibUCGNka86XakOBYE6ze9Fc5oaq5Tk+Jq65v97DZNnqwyGdVIle/2ZiR+n+ZMfYbjBl507NyBhrRTibv5itpVwYY4V9Ey2Lf0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000117, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On (25/02/12 16:08), Andrew Morton wrote: > > Concurrent modifications of meta table entries is now handled > > by per-entry spin-lock. This has a number of shortcomings. > > > > First, this imposes atomic requirements on compression backends. > > zram can call both zcomp_compress() and zcomp_decompress() under > > entry spin-lock, which implies that we can use only compression > > algorithms that don't schedule/sleep/wait during compression and > > decompression. This, for instance, makes it impossible to use > > some of the ASYNC compression algorithms (H/W compression, etc.) > > implementations. > > > > Second, this can potentially trigger watchdogs. For example, > > entry re-compression with secondary algorithms is performed > > under entry spin-lock. Given that we chain secondary > > compression algorithms and that some of them can be configured > > for best compression ratio (and worst compression speed) zram > > can stay under spin-lock for quite some time. > > > > Having a per-entry mutex (or, for instance, a rw-semaphore) > > significantly increases sizeof() of each entry and hence the > > meta table. Therefore entry locking returns back to bit > > locking, as before, however, this time also preempt-rt friendly, > > because if waits-on-bit instead of spinning-on-bit. Lock owners > > are also now permitted to schedule, which is a first step on the > > path of making zram non-atomic. > > > > ... > > > > -static int zram_slot_trylock(struct zram *zram, u32 index) > > +static void zram_slot_lock_init(struct zram *zram, u32 index) > > { > > - return spin_trylock(&zram->table[index].lock); > > +#ifdef CONFIG_DEBUG_LOCK_ALLOC > > + lockdep_init_map(&zram->table[index].lockdep_map, "zram-entry->lock", > > + &zram->table_lockdep_key, 0); > > +#endif > > +} > > + > > > > ... > > > > +#ifdef CONFIG_DEBUG_LOCK_ALLOC > > + lockdep_register_key(&zram->table_lockdep_key); > > +#endif > > + > > Please check whether all the ifdefs are needed - some of these things > have CONFIG_LOCKDEP=n stubs. Will do.