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 38DF3C02190 for ; Wed, 29 Jan 2025 15:22:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0EFD280071; Wed, 29 Jan 2025 10:22:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BBEB3280067; Wed, 29 Jan 2025 10:22:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A86FB280071; Wed, 29 Jan 2025 10:22:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 884AF280067 for ; Wed, 29 Jan 2025 10:22:35 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1C7D8A040C for ; Wed, 29 Jan 2025 15:22:35 +0000 (UTC) X-FDA: 83060856270.03.9CE3F19 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 13411140010 for ; Wed, 29 Jan 2025 15:22:32 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IRP2ECxL; spf=pass (imf26.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738164153; 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=s6XkNkMwf0es0PBIA5Ev2pBPlcQq5dWE/A5ck9n73CQ=; b=7bq4djXGQLji4Dd6d9iuH+zV2WsYMVf06yx6+KqOGADbh7SzS+r9Cydn54nUSt90xgMcLc RW6Mk+kL/0gkYJPidN++lPY/+d1yn+AExeR7iwYbO/EaTX+ymUdr273llGMLoD4JIozHNz O0P6jGFFva/i9QyM0OCruiaVlGjJBwA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738164153; a=rsa-sha256; cv=none; b=e1wjKvwg6K8Hmn7J23XKlwl0M9KNTgddwh5b45J1WS1tUOsiVz7GLbfPLeLOOtEr3f1nl3 9lvV2olqw50BmiUlnXkIS174eYwsaBk+SDQ4RysuSmaqoH94jNJyrp7Ib/QGojt8e+2mnH 5AjqoN5CsHp4zBdK198XW7V4jh+ePQ0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IRP2ECxL; spf=pass (imf26.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5dc59303334so2676864a12.2 for ; Wed, 29 Jan 2025 07:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738164151; x=1738768951; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=s6XkNkMwf0es0PBIA5Ev2pBPlcQq5dWE/A5ck9n73CQ=; b=IRP2ECxLAQW/eB4po09M4gVW4+TBM0TZvdzzq/lalEq6fH9IeP2sQAfCtE+fV+mNKy XaOWTpzCdJ7+JVEphvJiS0Rgw45lv4g8/+qzfxr4Azf3VvlxpLB3GXZvslFjhCAwhWL4 dGHjfIAaSbp0RNFy+lm7NfY1C421l1etpySwldYFaR6he9L3k4KZeuuaUHBt4dVLoNB0 EzOTsTwRUleQ6mdz6oshsQVOU/K8Vo4eRV31E0Xri/ux9kYKCvxXVxGOD6Ii/kc3wC31 4RF5nLtCo3XUtoDD/BTOyieuiImdIwNl6wMthQ1IKvWTgna7xneTnUFt/SKWR5kaH0jz k1Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738164151; x=1738768951; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s6XkNkMwf0es0PBIA5Ev2pBPlcQq5dWE/A5ck9n73CQ=; b=A6vs+zobd5R8Xy2kY/Y2fH1ZiaXuznWsuTcSZljVWbMLJheu1blb9HVhKJWo8R4VTe 4RQHLR4+T8zMLDPaE6OeDd6aLYVA6SNp/r8azAZ0J294m4ZCqA3kEQuadb9ICdimV1eb fSXMdMruUpg4GShWO4VacBmmQ0wIfw/t+wbNlQ9tjpdvGtA70c4AaZ2koHB+gOtFAuPG Nje5IH/5idYjx2ZQQOMDOYS3FkbXFEyj12aMJeZNxTayfvSTr0UrATliMxaeQc/zDMt0 YS4nBxtLKV0A0xh0PQTO9vTuMo+EOtfvHk2ds8xADeilNGgipkH8CykZUPgvwOjmlcXa Ap1w== X-Gm-Message-State: AOJu0Yx4xKuNLhl3UaiM0oHHXF3+Hwq2ZLEPCHz1N0ZCNtP/rW7L2a1N 2UC8NxkOdcDfbRyO+N3sYPQqRb64LqhLJazkZZvk+4esiDkRGT3X4YQcKQ== X-Gm-Gg: ASbGncvWuYce2RBthk4bfXowScST9RePVd3qd/uCxL1vqiH86SE2tbDeyAOmogAeQrO pgV+vgG+l430tmWnsURdWVnInOLxKeo4yX3tbNigC20lf/mJLoN2J+yGHaZO4s/zu78G2prULMw thx76xtInKm5Qn9394tGAvB3D02hG0UHBjP0NEgfJoPLH0XTZIUVsYXyKVduqGLc4h8sbZUEb/N ZIRhwKIckd1SJ+kiIiyIjkrmNUxju08pcKXDIuQud+lSCnlFDZTWcpc485aA49wZxYFC5qe/nO4 kLhGpxKAxpzq9WhS0uaemOrMejQ= X-Google-Smtp-Source: AGHT+IEPvsB5wiIxECbqiHsWlevGvuSZ+hxGT8O14vPvVJYyamCB8v5H9omglGOp8XAN26xtzC9nJQ== X-Received: by 2002:a05:6402:3217:b0:5db:da94:6e7e with SMTP id 4fb4d7f45d1cf-5dc5efebfa2mr3683306a12.24.1738164151169; Wed, 29 Jan 2025 07:22:31 -0800 (PST) Received: from [192.168.1.100] ([46.248.82.114]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5dc186183cdsm8967189a12.15.2025.01.29.07.22.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jan 2025 07:22:30 -0800 (PST) Message-ID: <3f787832-fbb7-8590-c090-1f511b16449a@gmail.com> Date: Wed, 29 Jan 2025 16:22:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCHv1 3/6] zsmalloc: make zspage lock preemptible To: Sergey Senozhatsky , Andrew Morton , Minchan Kim , Johannes Weiner , Yosry Ahmed , Nhat Pham Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20250129064853.2210753-1-senozhatsky@chromium.org> <20250129064853.2210753-4-senozhatsky@chromium.org> Content-Language: en-US From: Uros Bizjak In-Reply-To: <20250129064853.2210753-4-senozhatsky@chromium.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: an79bj4cbu5z1nedkaez43qe84gy5rwp X-Rspam-User: X-Rspamd-Queue-Id: 13411140010 X-Rspamd-Server: rspam03 X-HE-Tag: 1738164152-358951 X-HE-Meta: U2FsdGVkX1/0IDJEtkUJdguPOjKjhTV/XW7HCseM22Vd4gvzvA57V1QzRQz4Holk5jLojPsss52SHKR6vWGq1nA+KQoEEGHO83VmMxxpIjZPlQJf/yys63T1VkAsLsgx3xjn+U+9EsLIU4AJx1B0YBxj7utfRDoS6wAjW3MjEcH6Hg0kzrO5wqy1jQ1NVyQ6+b/VWSwbSpwGRXX4BXsoqOgzWGI+QNLffutT9l8Q2fwQ7YQqTLZe50lDF6ctEJyEgU0s48iS0BJ/c6/3gaEFn33TYE+rujNprRJQluaLu9ZoWy7s0esOwX2bjqKtfgkeQ2oLRuaJvS1dx2WVDqcNDPCHG3a0GsXireYJ8Kr1NzqGZQUuREAjL1a1MFyzNel4TdnZST+oIDqDJA/29nJfNlWGRXoym6Nfm8qnlQBF1vKrEyUfy57AEB+Dw2FGb97W1eRFW3yea2YC8DwG7fOCaksj/RxZBxDZhqQAkcsWZNUu5NDVphJWvJZVA4ZLoFWE+IhZfP1S57Xpa3fSUx6YGpSCoKMalvMiiW/UQCsBy8vZXR9I8BlEudOpZgWsbRPco/+9RC5RAwQBK7ZKjf7CODn7XcCwvBhL+ZVzYaFt5kb9aGy0AS8sYkY7WLZGSGil5b9cfUDSvcQP0V/Un28WLL3coW7LIiguogrbROQ1ybq+q23xxojCByRRAPABP4cTzYM40EP8fI1qla8zlgUFOJwzv/Kdl7ew9dnuMISSTJqlCWLMKfK+xLSvDdY6carZKrv6ALDTEPsp0alCwjKkPnJ17U04qTZHOv9wFt81Jp/yK051B1Rqrdvy/yLZCrO1AqTAy7gwc2Ys9A4GkwSsZrJlWXkF6l223BCizAw++zKSgJLk0HeZ0ukacWfe/esAUNyURXFqUiacAKTXt0elwM8bfCMIhQORfJ6wEIaifhtf3TGHV1Xs6GXFLKDWJqs6wCcy1c/H97NsRKIdedC g4HNh1wG swowzU7idiNc77bpB2qcBJm/Nw9F5YIV8wMkMO1SIyjpiuly6kNOAioOQ/8VHqfenAZ6B95YbGrdbEZZtcTGIaOnmQevMR2FP4PqhyOB5WACpskH16nAlvDOJf8fHaDEwnyZ+cLko3m+zuIym7SXn8jyc1JiOocbEemXsWSgRBWpO0sZZkj/YuZqdG147AUEeyQrVDXZ87cTwhvgifPG0rInjcMpGZZ0tExgRdmdAa3IuSBEHQduclLVW8vR2VwmKEMXukTcnmb5JwAN0CI5dxA70suDS2NtAHZ5O9bCAlmf0oHiCybvhnAIHFG+Aqe8eFXkpZgQxdKL4t69kiX2a2g7D3KTW3t0qeF+WdYkfXxU1Rw/fzDexkAZyfKB+A+caS8z0xIfMrVgPuy7WZDJRaXVXZw== 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 29. 01. 25 07:43, Sergey Senozhatsky wrote: > +/* > + * zspage lock permits preemption on the reader-side (there can be multiple > + * readers). Writers (exclusive zspage ownership), on the other hand, are > + * always run in atomic context and cannot spin waiting for a (potentially > + * preempted) reader to unlock zspage. This, basically, means that writers > + * can only call write-try-lock and must bail out if it didn't succeed. > + * > + * At the same time, writers cannot reschedule under zspage write-lock, > + * so readers can spin waiting for the writer to unlock zspage. > + */ > +static void zspage_read_lock(struct zspage *zspage) > +{ > + atomic_t *lock = &zspage->lock; > + int old; > + > + while (1) { > + old = atomic_read(lock); > + if (old == ZS_PAGE_WRLOCKED) { > + cpu_relax(); > + continue; > + } > + > + if (atomic_try_cmpxchg(lock, &old, old + 1)) > + return; > + > + cpu_relax(); > + } > +} Please note that atomic_try_cmpxchg updates old variable on failure, so the whole loop can be rewritten as: { atomic_t *lock = &zspage->lock; int old = atomic_read(lock); while (1) { if (old == ZS_PAGE_WRLOCKED) { cpu_relax(); old = atomic_read(lock); continue; } if (atomic_try_cmpxchg(lock, &old, old + 1)) return; cpu_relax(); } } Please note that cpu_relax() in the cmpxchg() loop is actually harmful [1] because: --q-- On the x86-64 architecture even a failing cmpxchg grants exclusive access to the cacheline, making it preferable to retry the failed op immediately instead of stalling with the pause instruction. --/q-- [1] https://lore.kernel.org/all/20230113184447.1707316-1-mjguzik@gmail.com/ Based on the above, cpu_relax() should be removed from the loop, which becomes: { atomic_t *lock = &zspage->lock; int old = atomic_read(lock); do { if (old == ZS_PAGE_WRLOCKED) { cpu_relax(); old = atomic_read(lock); continue; } } while (!atomic_try_cmpxchg(lock, &old, old + 1)); } > +static int zspage_try_write_lock(struct zspage *zspage) This function can be declared as bool, returning true/false. Uros.