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 19A16C02194 for ; Mon, 3 Feb 2025 12:40:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A550280002; Mon, 3 Feb 2025 07:40:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 85446280001; Mon, 3 Feb 2025 07:40:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71BC7280002; Mon, 3 Feb 2025 07:40:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4E804280001 for ; Mon, 3 Feb 2025 07:40:22 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8D3221CAE0D for ; Mon, 3 Feb 2025 12:39:23 +0000 (UTC) X-FDA: 83078589048.16.DACFDFD Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf06.hostedemail.com (Postfix) with ESMTP id 90AC6180003 for ; Mon, 3 Feb 2025 12:39:21 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="oaAHn//2"; spf=pass (imf06.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.174 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=1738586361; 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=2k+Kz5fKQVWiXS0aik+0OS30foF5H1QAZ5rCJu/Bzeo=; b=m+UT1MOWBisP4UfxV7NlYjJvTyBC7PnYM8LYODbPtgII5mtXsYkOfpxpG1c0zc2Siw57yc 589HnsmKVMgJvNx/o/HkQewsZnWTfUNcoTpwiycmLbxlgrAnDH+xJqZ+b3DkuIxYZ8HhET PUlONsL1tv37+mbhLtTU0wCQEHxSo0A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738586361; a=rsa-sha256; cv=none; b=a9azLHC4qXbJuwApanhK4dxDGAAlsrTqdXL+J1p0ZaVRUe2rwZmCQk4TqGlQ+m+qcfKT+Y MyH+V35p6DnZn5Bd9LGmbCy4oLYp0ia7NtFpvnvNyx7wJbZXMzD/fTUYQUTCdQ5BuLQPm2 1dfP0VuhP+swFM6P1vMTZOuEPQWgco8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="oaAHn//2"; spf=pass (imf06.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.174 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2163dc5155fso74521565ad.0 for ; Mon, 03 Feb 2025 04:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1738586360; x=1739191160; 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=2k+Kz5fKQVWiXS0aik+0OS30foF5H1QAZ5rCJu/Bzeo=; b=oaAHn//2XR64C8y6mYcKHmYcxmfRqN93JYEXC3d2O/vChtJX+KJmBsNNzuyEL5sxNm ob+1K3LwkPkiyhmZkOp5oNO56LHR2/B6V9qG/ug5BGyLFpuNnbzt5r680L+skmRuv0Bk khqtGA/cHerZx/ZV62UkeTOhJoYoKczc0vcvQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738586360; x=1739191160; 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=2k+Kz5fKQVWiXS0aik+0OS30foF5H1QAZ5rCJu/Bzeo=; b=t5GuJjN27zZg0CVWmvKRSkZfzVlDMAyWJv3YazXDCbjthrd//fml9zkOKXBjCJwzmj 2MT4zv0ao6s5PwhzFZ+JZ/UZXbuphbvJ7n+88ipPsVDhpbXRww9FZoeKbvJE5rupOjYB JVE3sMGqa/0Gi+ZXQT8Yh96G/l54qWdu8Ko2WzIfPEulIH21f9nWzx9VrCZCuSJpQHYf Ne53/WcC8oV3MNES9DEtdhrkCvqBxYNV5GShbT9AreJQ5WOJ0ls27MbH3xQDv67oGCMV TcAK/jcPbvc4y9/YUTRg24VUmunGvQ9ICPEIByRbIEd9hqU70j3FW87R1w/qIc+RNJRx BzxQ== X-Forwarded-Encrypted: i=1; AJvYcCVYyEo9qGanNlGqiL4OV0jfdl1+Cg7daLmmXKaTSugHGawNxin2AFofv38ziJLntTjsAQmElfNLVQ==@kvack.org X-Gm-Message-State: AOJu0YwZoBxCXauJ+sdplMZ7ukRJESwO1uWjXBJxlRX0ImGg5lbBDyyN S/n1cNXsEKuLz80Girdo4Q53y4nNhqJTWvYm3LlEx/yJrUlX7tl+rER/J0oGqQ== X-Gm-Gg: ASbGnct+hWSy0UE7y7LxJb1BkiSBwyCEQHFp0FTPd1FoQBp8Kr5vVarjC7RHx7i9Zhp TkGweN5fVL+ey6Lb10QzkAP4Px4L/a0vPQmn8en2/x98h0doCZ31/HymU7qVPwTXuyqoBRh+maz V9z7F7Gh25DbRv/a8k6zmgsIGnaYYDVDn8JalNmcY+qK77YU/5cvVQJpnX794onMKLq8xBb879y 46jxInLBfEsF6wtjI1wGbiaC0WH8gOO8bblwoOZ344Y0lxhK3eMsc8SeW6KtFE4eXzeJ7p/kfYS 1IBwEsd74zifunu+fYQ= X-Google-Smtp-Source: AGHT+IH53BmAw8JAIQ38k4OdngRGhoWr4a8BEzvXCGZCeBs0F891N/md7nrjKD8eIErTXuc4y0bTng== X-Received: by 2002:a05:6a00:2183:b0:725:c8ea:b320 with SMTP id d2e1a72fcca58-72fd0c04c45mr27134735b3a.14.1738586359958; Mon, 03 Feb 2025 04:39:19 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:b77f:f2de:f99c:2d0e]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72fe69ba468sm8234757b3a.117.2025.02.03.04.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2025 04:39:19 -0800 (PST) Date: Mon, 3 Feb 2025 21:39:14 +0900 From: Sergey Senozhatsky To: Hillf Danton Cc: Andrew Morton , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCHv4 01/17] zram: switch to non-atomic entry locking Message-ID: References: <20250131090658.3386285-1-senozhatsky@chromium.org> <20250131114141.1870-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: b19fiowufj6ca1nphs984b48kf7seei1 X-Rspam-User: X-Rspamd-Queue-Id: 90AC6180003 X-Rspamd-Server: rspam03 X-HE-Tag: 1738586361-999896 X-HE-Meta: U2FsdGVkX19U2oORLMLvgDHtVfKEHAPiKZFEj3wt9YyR7QlwSUWE/iCwAOa8umvaRQ8oK21hsAmOygWf1/t3T4knxKvBCLynrqfLgZjBqImpv6+YDEv7orLQvdaIZjTjHrzwc5KUzPj9WYtgqBcBgQN6VYWgyx4pDDMyaSHi0M3RUeTPPKNnah4yNJ1yqr3v3LM95q1JlJ6OpOUQmyK7/zJio0YiB4blpcgnqLdq670OxV89VNA/jcVtut8IQTPSeL2cxPcmWmyFMBDewrIlG7PIpWJlk9OhjLYEXsu3euUY5e9k0qnl0pR0CsvKqV3zVX6SNPdMxPygECh18KQHSVVxFZOVQH2GQdBjYdRnkoz8Pxo0M5dV6rvYfj+UMu8ooDxVNC/Kij5wi4njyEseHCAYJ74pNkfHxCUaESZocAqR8ddYPuN+5NGYF6Ppz+kR3UjdG3ZkmWDK5R+02uELJ5HzlEQ5ez0Zj6PcwI78m8iixuumuFAyyzUDu0KKbf9OABNFHg3VKc+P5ytBbgkIMEsesIm9/vPu1U/AGFFAhb5FOI5RH4Xb8c+1sAXdVJwds/djJLBsJQrCYaSuh8h4PgVzsq4vl3yEwTBjqy+Ns6W3PPR+fyXVGLzNmM79ENZcv56x3sjahE5GBQjcWx1MWU0MH886MQ9f3ug4K0m43eNUUGFnNDCFGf1P9WorsmqTvvuiAHt+VKuyNUTX7VzhEpBq0RhHpXGZ39W4hmpTa1SoejLYZStrF7UbK/UrMptSNkmc8/Qq2bsiXzB0NhbUYEq5qdmgAT4g9xPIAUCWGEuypZPVesm+wZeWblnV3PcBYEE+CvwNgNQZaIRf4ekl62zV3PYvg2jbBgp5VN7871Orzn56cUCBq+o0F6LYhx0t9gardnUk+G0mEuqf3vuJ8Qe0jcwp2p8Xp7wRcP25tkERs11/ZE5JcdMLFEg8E5451m27Df4cwpT5Bonlab2 LJoDzKqB FaBEhDki6/KSUfw9ILWsrOat4lI5qbbkI2LoHQ3ps093YO9+Cjq3gkGIufvoGIBYtJ3uLW7YGGaPWEkfXRJKezL4whq2auzFze3B3ADpBnQCTf1fxBTaSCBBLriV4h5dQtJfuWse1UjxnXNyWHLQiuINwkkolbtWa7m1b/65eFDpxKIlarXWkrCSJFf24+3akyhFIvUBw9XdUZodH+Rn0b6wnlqNSgyBCREf/EqE7JS00d9T6r2fwd87xvZZpwTVJyaFDk1UzDrD6TlVF32+MyAr+Klc+anCXQUKn4oto5fJm2O4cFw+XtmeoylBD7bAjZLPXd+WhjxyG2b63Izm09wv7vOc5ka6LljtjyZ/N5HhFj+Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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/03 12:21), Sergey Senozhatsky wrote: > On (25/01/31 19:41), Hillf Danton wrote: > > On Fri, 31 Jan 2025 18:06:00 +0900 Sergey Senozhatsky > > > 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. > > > > > > Do not use per-entry spin-locks and instead convert it to an > > > atomic_t variable which open codes reader-writer type of lock. > > > This permits preemption from slot_lock section, also reduces > > > the sizeof() zram entry when lockdep is enabled. > > > > > Nope, the price of cut in size will be paid by extra hours in debugging, > > given nothing is free. > > This has been a bit-spin-lock basically forever, until late last > year when it was switched to a spinlock, for reasons unrelated > to debugging (as far as I understand it). See 9518e5bfaae19 (zram: > Replace bit spinlocks with a spinlock_t). Just want to clarify a little: That "also reduces sizeof()" thing was added last minute (I think before sending v4 out) and it was not an intention of this patch. I just recalled that sizeof() zram entry under lockdep was brought by linux-rt folks when they discussed the patch that converter zram entry bit-spinlock into a spinlock, and then I just put that line. > > > -static void zram_slot_unlock(struct zram *zram, u32 index) > > > +static void zram_slot_read_unlock(struct zram *zram, u32 index) > > > { > > > - spin_unlock(&zram->table[index].lock); > > > + atomic_dec(&zram->table[index].lock); > > > } > > > > > Given no boundaries of locking section marked in addition to lockdep, > > this is another usual case of inventing lock in 2025. > > So zram entry has been memory-saving driver, pretty much always, and not > debug-ability driver, I'm afraid. Before zram per-entry bit-spinlock there was a zram table rwlock, that protected all zram meta table entries. And before that there was a per-zram device rwsem that synchronized all operation and protected the entire zram meta table, so zram was fully preemptible back then. Kind of interesting, that's what I want it to be now again.