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 46B7AC02198 for ; Thu, 13 Feb 2025 00:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59FDB6B0082; Wed, 12 Feb 2025 19:08:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 550046B0083; Wed, 12 Feb 2025 19:08:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 417086B0085; Wed, 12 Feb 2025 19:08:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2433E6B0082 for ; Wed, 12 Feb 2025 19:08:34 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9AC36141264 for ; Thu, 13 Feb 2025 00:08:33 +0000 (UTC) X-FDA: 83112984906.30.EB755A9 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf27.hostedemail.com (Postfix) with ESMTP id 0175440005 for ; Thu, 13 Feb 2025 00:08:31 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=SVY1aBb6; dmarc=none; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739405312; a=rsa-sha256; cv=none; b=cDl/LeNOcl3PhWUnJdRybTaVzFAiIqmkTfdhW1v+Fwq1meWKV5sHiX3gHTRZewfvOxYemR PFqabx4xiirUrQxCP7GPEmicTTe87zBRvW4/O02mrAnjWBqS5TbC3fdC415fkjkf/FD+ki HQiV/XISIBsAlSQA7B4GaoBd65I59Xs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=SVY1aBb6; dmarc=none; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739405312; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=blEnh0n5hr7zuMN1kAYkJ8ssy8I7x9pYK4vViQg9mro=; b=AAQxkPbDlwUHtEu45RqXNQlXrV+f1/0pLg+dKVpeqgoO0TW7UaPdaiJ7/7jtWEr5qmxioB qIcgP5o9prHn1itP6W4JCKCyG/C29NhUVxRzJuUvSLcqHbKGWpxEKeydGLQcUnmEJr5AdN 9FvpDzVEBpwn0JIEmAtmj2syJ7Hsr9k= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EF815A41BF7; Thu, 13 Feb 2025 00:06:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BCCB4C4CEDF; Thu, 13 Feb 2025 00:08:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1739405311; bh=Ay+MnAffsrmvsH0jD18LAzU0xxhWGvUHK+WQwsePY6Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SVY1aBb6LEGP+BLLUb9e1t0E+T6a9dZEnhZT4qrJVl6AZYNSujmiVCG8ZKfvXa3yx L5VSfGoXpKjdgSk7Th/9B7s7iTSeXVuUvtIgP3kas0YHu3ssHPfwpMY0ijFddQISbQ /Xx8+oLsr+K+s+XbJxWS7SNuC23ClYeflmZ+GdlI= Date: Wed, 12 Feb 2025 16:08:30 -0800 From: Andrew Morton To: Sergey Senozhatsky Cc: 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: <20250212160830.730a199935e907c2498b28d4@linux-foundation.org> In-Reply-To: <20250212063153.179231-2-senozhatsky@chromium.org> References: <20250212063153.179231-1-senozhatsky@chromium.org> <20250212063153.179231-2-senozhatsky@chromium.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 0175440005 X-Rspamd-Server: rspam12 X-Stat-Signature: xwg8xcw6ooqakgcenqxi9qfrpmowd57u X-HE-Tag: 1739405311-659747 X-HE-Meta: U2FsdGVkX1/vjaO0UOELLHilerNLBXhnyzE3vy0UGBiG7mAl4NESJi86tyiM8IDuFwgt+La/QJNpFNpvfPCMJ5in0FdDfBSbzEEYvau2mBgVuiIyhoy6vPFc9P8qWyTuX6c3pIeTabpG0poypW0R4Vg0RfqCkoHZ+7CLWK+v/tnICiAe/dP2URdOeoSlfdMT46uBfZrUyEk3VrwPEGTd0w/+6tB5ZAKzosLgUNChNL5GLuYfSs6u+L0Sd5kKU93u0wE91tMn+aZVmTjJdKDhZdH10h5D9+iFeLkGUYE2X+QCtaNcUyJ5yGhxyBS9CcCXxEjMYXfmVK+SQCZD1kLZciE2gapg/qwSUlc75c8GFY1Vc2jiZj2UJuIzaR6XO1Wv3TUNN49gXDE6RyYsjWiZBUYISzQs9Uj29e6EVY3jMsyADFQ50cd6vBbXTEpwDEjHVuB2ks7OXPhw92RwjyJ3OYuY8y/L6De33/7PIYI8sU3MK8fl2kcD7eY6MA2KhvFszmzB48Pk0CA2+jrrlxMbH+PZEwxj363yCBEusnaQ1E4NIeY9m1qllQXM+JwDqJwB9nPczOA8Skmh+bhMNnHofVyiax0Lyt4rkFFbUOYZ+NjQujqrytsk72QHpsG/OHSxEIUX1jFqtQBiYfT4F+pnd2ntmVyj3SDQUX8AwYWrbRC2lZ0JgqUfW25ZEQBUJnH70cc8SwqmT1uTwUqqTNxxBlEhHJv9ZD3NUAPZ7FRexapxaUFqbT+Onr5HMGvVHWamSfhjbV5bvtyp9/s4YHnZ9OK/pseSge26Qpja2bJKofl+ZA6e3+ydJSHiUIMhRMF+VricEF9cL8TzFinKCcldkig1io1amAOA6W/IMm1jwWhsJRf3AEencw1B67HU19QcDO6qC6qDSdO02d58tfqjULioAHXvS9D3C64XXGs4awCqMvc0TTWzhgXvDbavHUJiYjT4PrRwSBReIbOewgp CnJFfidi yxA4Q1t69N97nLcs0XhBYbwTxF/+ynF+c3Ta+DZ/IhmffWUbgKBwVQeCZEpiflyVYKdgkSny2wX6CXhJ6IqGKTf3QITItr9YFAImIhE8rqKMHa8+EN5qwTGhcBm2437E6YHWqibPw3ubqubcCBfuoD2x3maivJSuQZ4NrUh61dFz7ZdwvvNheNnYSjd7QBMQL4/G+Gsdn3J6/WBgkP3SCMaxdT7ge8B7zcrUsTOvDqSp31oiw4JBMiANV3QxstgAFodEbHkNqnTeinAA= 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: List-Subscribe: List-Unsubscribe: On Wed, 12 Feb 2025 15:26:59 +0900 Sergey Senozhatsky 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.