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 2D261C02193 for ; Mon, 3 Feb 2025 07:12:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3889A6B0082; Mon, 3 Feb 2025 02:12:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3385B6B0083; Mon, 3 Feb 2025 02:12:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 200686B0085; Mon, 3 Feb 2025 02:12:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 028D56B0082 for ; Mon, 3 Feb 2025 02:12:09 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6756E1A23D3 for ; Mon, 3 Feb 2025 07:12:09 +0000 (UTC) X-FDA: 83077764378.06.3983BA2 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf27.hostedemail.com (Postfix) with ESMTP id 782A840008 for ; Mon, 3 Feb 2025 07:12:07 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DYURRhAN; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf27.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.173 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738566727; a=rsa-sha256; cv=none; b=ttD3ZmgmuvPZmbWmdVNghwlnqXeBtIupGQAHPKk5Ie87FJcqe13F9JiyMzXBsJ2vPGSry3 NdTRJ/U/mS3VR0CQCyL4H1VIl/QcJe02DygXxZeidYa38bn+IIifnIxOHJZJzUmzgtZtPI kr9bmPU9mpuX/Ss5cImkCcuooF5Pld4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DYURRhAN; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf27.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.173 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738566727; 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=jovPlsXMD8ercV5vJxs/GxduF9oWwr/XATh+6VZzu5o=; b=Gp1HaARwjRZxDkymijHGaYFhbx2DKQFcKkaA9UoThekJja3K27/cC2CEWMuIQCtjM5hutU KiKXGwSPe9EaE56hDc4kAVZTWgj5Up6SBnHNlPewdhbmzE9tx7Imn4IdzuivNP0pbUt6wX IBGgybMtPYRJz+D7k8NCIGwz99wZj44= Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2167141dfa1so68800305ad.1 for ; Sun, 02 Feb 2025 23:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1738566726; x=1739171526; 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=jovPlsXMD8ercV5vJxs/GxduF9oWwr/XATh+6VZzu5o=; b=DYURRhANEZH6QV0qbvNYaPo8ZHoN4pIjbkWiihjVeO82s+pQPUtEwsfUW1EX+DoaWu /5QVWoi0eYiGUiQB3vbuRPc+6KeWxZTLNIHxdG2tU7YAaOdbZRvn9njhM5ai75cKMas8 /jO5hz36d7t4QMw3Rh7UsspC3Ny4j/Drwwh5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738566726; x=1739171526; 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=jovPlsXMD8ercV5vJxs/GxduF9oWwr/XATh+6VZzu5o=; b=cM4OxlX3+qy/usq10LnYySkGgjurfns8hbW5RBhibCuk59yujJW5qpqOIiBOFQH6gu BBJHaOCyoBM1aTyc8SyyeFYA+Ch/wZbSQ/B3G9aav5pR/Q0iiENXyPo/s/PWulB0Cr82 Hy9WMu+v1PaC5tPKCudWcmjpqwcFhkFM8JEf0I9paJpW7L+GacPuKfVxeZ3SxFAAo8xb dsm+gp3ZZIIjXZ0/xZEmUBX2LWOhsqJrCgNuInciEhb87gm3EsZSvaJRc3TnTNx0IR1D QcLi5FbvgyuWomD1q5EQe86DsQiSs8GhOhjryWAaAZpx3KTjTSBFhMp/7jTb1dSCsc29 AlIA== X-Forwarded-Encrypted: i=1; AJvYcCV2T/IfQMyX7TgND8PDKSq0feEnfIoh1IVaN1GG5qqKi4U8izLfRjSgenokb7F6nGuir+MF57AZ/w==@kvack.org X-Gm-Message-State: AOJu0YyaKAjE0xptvTU9a+KCazi+9ShmDqd5oeOse/UQMVRIFbN9ZeKP mwGB1dMxxZuyMI1PcRGbN69nOAXqpQmvjBgvTQ+PTOkYatKPf4iGVoeNSsE2HA== X-Gm-Gg: ASbGncvYoV8inH84vE/ntbmQQbxgE190b0Bph4tsiAAR4rakFHsOBzaTHl+5mq4n9y5 1iKu4SMFJZCEWvXn/mFw/19hj+LhrlH9M3OquaC33WTyaH9pvlB5tnowFSTAe7m+KbezJntU+RU yshyhGEAjdmE1IpQOww8vPpM0aRKxbaSDX5uamJhc5XXMcqfyCVGi8zliRefdbkKgPGli7jAEAu IKuTn6XlWh/xFRm0BIF/pIhS0tZbjEY2AH0KP9vsfzp4KaVjLSjW++mOIjqL09/3uxenCLYp/Bz DggcTfPy4F43paHyFnA= X-Google-Smtp-Source: AGHT+IGqQ0PsxVAoOO+ElcY+N0qt1g48OM/XXdS8cTwo49Ct8aebIUudjNCCzURajXn8/tcTIjIyig== X-Received: by 2002:a17:902:e342:b0:216:4fad:35d0 with SMTP id d9443c01a7336-21edd7ed325mr141655805ad.9.1738566726025; Sun, 02 Feb 2025 23:12:06 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:b77f:f2de:f99c:2d0e]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21de31ee1efsm69263255ad.28.2025.02.02.23.12.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Feb 2025 23:12:05 -0800 (PST) Date: Mon, 3 Feb 2025 16:11:59 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: Sergey Senozhatsky , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 01/17] zram: switch to non-atomic entry locking Message-ID: References: <20250131090658.3386285-1-senozhatsky@chromium.org> <20250131090658.3386285-2-senozhatsky@chromium.org> <20250131145536.d7a0483331b0ebfde80a5754@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 782A840008 X-Stat-Signature: u9p8h6edbdjhykw63pe4a88w83joxfwq X-Rspam-User: X-HE-Tag: 1738566727-199474 X-HE-Meta: U2FsdGVkX1/VmzRaVgxbxMvfzzHy5lMpDgOWc0foUI/4swIdnEggWofTeh+Do+84nvrjGCqNPTwI+EgqSQQsB8OSP3ScAd3+YMUBuDoJrUAhneG2tekJOPDF9fQwP6yg0zQxzKvuxV9aIE1DnR1v4IO+PPRgY+PgRAliJEbr6y0SLEMCe6t5As01IAkjO8Rq4BSOa9537RTFJR82yHkQb6tgfeshJ34b0AlueUnKq0CucUvIK1OTYOoBe/o75RIC31U5Ua1XJYYd6G/tUry4407ek9MXnlC3Z91sx5ZJxNKTZ00EOofCCI7bxQmciEQsQyk9P9URXmFIx1aXtqKJoGXldnicq9cNIOWWqLQN8q3nYHjxFTtoFVsjQiIcAHYbr/W2tJYL169zRcfYYH8EYzNDXRx1SkjchkQDbib2SONfQnG4bL5a9gZD74d87yRRG6rjdAQIqlGzg+Glj99YCgNNk8PiyAsfpvqAWIFheXC76UTWrw3yB3SdzOuS/g6VCFOKCJiuhhg94pMqluOCn0hqc33BT1vtmBZCCEOUEgXVYlzI9Q5zFOJgehPbnPVvB3UBeSiN+tBUpqc54wTXXHDQu+V2Qukrs8pPGI9KhjPNFIEU8uahzH9ucxJ5zcDUuDc0mxwzTyzC3SAaZAxTTj6TIV3mSrTViGwtsrP5UCiC/IbtZpaYuc09ZY7jHgpon2+M6DzVRd/yUFNyJcDoAT92fhlKOU8j8yVyM0VjxLjvfvVCXr0Knd7zDToljLigKzs6DL4l4B9bfaTGbUIh/DjLIVabVgWMDR7DxgS7mQ2te2yfIG46UaUb4RJ/cpGh35N5VKwJW5NcnLAzHvMasxXEo1oRPSlmBEdMr8Su8RvTi6ohELkqtCbFH3RT5yQLcdlx3KCziW9xFLQ7VVEZz3kbu92HzWP6B6loJHt8TczOsOVyTMtc+4AMYx3j9I96c1vy/PiEvR+Z+ylkWnZ wo/dpP/D f0nqb4G/XGRHjykSgq67vBV9Uw0AWg5+EoXkwatfaRxKWrysRmJfnLgD0IYHLH6aYTkSGEW9wvRYbl4qXOOcJxyS6SKVOZ0qG1THBz9xwyN1J3qaa8QRb/zzCojipb8ZXv1eN8afnc4/QRV8eruaj37MBtmadDoxNhOXqEt29NsYHzJE65YThSXx4SEqnGuLWmnmgzTTWB+CBFmsKoQByrtIGTm0cVVP6TJpXSdq669o/CFaurcUcOvh2+oGPie5XagJ4dXD6lyvRJbeHiH5u8iX7b4K+aK4utKcgos3DlviBH/aMJvUd5w3Yo7xfFFKusS2O+sb/0DapILMb5a3DOqrJorE7xvXPWGA+QTF8b2oUNhw= 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 (25/02/03 12:26), Sergey Senozhatsky wrote: > On (25/01/31 14:55), Andrew Morton wrote: > > > +static void zram_slot_write_lock(struct zram *zram, u32 index) > > > +{ > > > + atomic_t *lock = &zram->table[index].lock; > > > + int old = atomic_read(lock); > > > + > > > + do { > > > + if (old != ZRAM_ENTRY_UNLOCKED) { > > > + cond_resched(); > > > + old = atomic_read(lock); > > > + continue; > > > + } > > > + } while (!atomic_try_cmpxchg(lock, &old, ZRAM_ENTRY_WRLOCKED)); > > > +} > > > > I expect that if the calling userspace process has realtime policy (eg > > SCHED_FIFO) then the cond_resched() won't schedule SCHED_NORMAL tasks > > and this becomes a busy loop. And if the machine is single-CPU, the > > loop is infinite. > > So for that scenario to happen zram needs to see two writes() to the same > index (page) simultaneously? Or read() and write() on the same index (page) > concurrently? Just to put more details: 1) zram always works with only one particular zram entry index, which is provided by an upper layer (e.g. bi_sector) 2) for read read() zram_read(page, index) rlock entry[index] decompress entry zshandle page runlock entry[index] for write write() zram_write(page, index) len = compress page obj handle = zsmalloc len wlock entry[index] entry.handle = handle entry.len = len wunlock entry[index] 3) at no point zram locks more than entry index a) there is no entry cross-locking (entries are not hierarchical) b) there is no entry lock nesting (including recursion) I guess where we actually need zram entry lock is writeback and recompression. Writeback moves object from zsmalloc pool to actual physical storage, freeing zsmalloc memory after that and setting zram entry[index] handle to the backikng device's block idx, which needs synchronization. Recompression does a similar thing, it frees the old zsmalloc handle and stores recompressed objects under new zsmalloc handle, it thus updates zram entry[index] handle to point to the new location, which needs to be synchronized.