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 7DC82C35274 for ; Mon, 18 Dec 2023 11:26:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CAF38D0007; Mon, 18 Dec 2023 06:26:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 179F58D0001; Mon, 18 Dec 2023 06:26:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0685D8D0007; Mon, 18 Dec 2023 06:26:58 -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 E58F18D0001 for ; Mon, 18 Dec 2023 06:26:57 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A5887141079 for ; Mon, 18 Dec 2023 11:26:57 +0000 (UTC) X-FDA: 81579712074.03.0C9EC66 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf15.hostedemail.com (Postfix) with ESMTP id 038F6A0008 for ; Mon, 18 Dec 2023 11:26:54 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Zy+FJvi3; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702898815; 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=kfKoRLV9oJp0z3qD43gucxUcp/9jii5+iBZKMhLvNG4=; b=4EXWYKyu86isCzN8xrQuNNdV+TEaVfPJtGmBssC0gRZFcSmXqX8Q8usL8E9JhW0Gquh8ZC hRAqdXIU3oHxSCg3kO1kF6mFGWkHMbghj2+c99TKzlKTELCx1XXqzdSS1cLysnMe/iPaYS ZxcrIzGaCjjngXZ4jZQkf5/C6bEFsak= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Zy+FJvi3; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702898815; a=rsa-sha256; cv=none; b=V2Ek9kpcdXdalwUs2+gCVQhP4uDI7+zd4LShNQGhnVy66tXWWzv6Lg848e4CwERjUXzUN3 0qHrHgha7ftqoCWHNwdJXUylGLKc7IHF2keTj/uoCxaZNaNYt01mnWUOGbE3HHNdj9I7JW bNVPpyO+HgcOyrt2UCxZeLBzDfWiUNc= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1d38bedd799so23793175ad.0 for ; Mon, 18 Dec 2023 03:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1702898814; x=1703503614; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kfKoRLV9oJp0z3qD43gucxUcp/9jii5+iBZKMhLvNG4=; b=Zy+FJvi3IVYf9uNzsjISCfel1OGGunNOuYo8DoXlQ6D6QcYdjnTjYerd5T+aN1voZt 2Rv+hhOXZjLG2F6fk3FBawZZezsBt7hr5vOcZ+U2o2UzkreCnyfVYqGY6xdv5st1/VSG 7uUJn4I/MJmzEuoOxHB1dQBdzWUOqDVpkomq9trvpym/6vF0Ke/5R7GmlxsLctDmTQ9n 2hgnUM6+YCsrO4/fJgg7vrhnq/Pd4dDRmu7iB8MsEMi36KlSfyu+bVNo0K3SXyG3sLbs 329YoI9iL4ZX6/CXfUaIomCPnaic6wb2FDbN4GsApn5Tiewr8dzM3dnO3lAUgeJVZ7BH lOVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702898814; x=1703503614; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kfKoRLV9oJp0z3qD43gucxUcp/9jii5+iBZKMhLvNG4=; b=PSLEP/qQqVeV4OVVEo7GzvtzV9SSxE8YS6M9kFDaAzQ/Pqk2HeUEkoah1QBAgf0C9y fNNOrxxmv7K2mexSzuaZWvtC5yvZUSg96i+Wf0WBdxDRr5W5V9TauCi6E/EzPLoNOdcY go/MggYgZmtA5T3RPeA+zoP+2P+FG+OlLDjbXl37eBUVtSgi9fPBjsxhMZaIjrYQlUys 8hrQrxYuhp6gMUDA69OndDrrAz28M8tRf+vj2TxjwyxmDd/cyODqSatpjVEa+3kAZ+qY PI/Rs/su9ebSeqjENeWcMQ+jbz5H+iwZqxqAD1cS9mhvAT3tSA9ZzjRdIJYRZvbqwOi7 IoiA== X-Gm-Message-State: AOJu0Yx1nUAzeGJ3mQKRUTPYzQ79BytrGijggqNE3hvOib43m3F4tlcZ P2GNGLEYIqcMTBotzm8WcJ7Zfg== X-Google-Smtp-Source: AGHT+IHDg2mX/8+mIoUoJv5lZOdY4IClX4/y+WxS3+zhFVNhCFF73U6DA57W1ux2VpGkb6k2X/2SVQ== X-Received: by 2002:a17:902:e54e:b0:1d0:b42f:e41b with SMTP id n14-20020a170902e54e00b001d0b42fe41bmr18377215plf.64.1702898813773; Mon, 18 Dec 2023 03:26:53 -0800 (PST) Received: from [10.254.38.164] ([139.177.225.254]) by smtp.gmail.com with ESMTPSA id p6-20020a170902eac600b001d3ae3df256sm2369851pld.149.2023.12.18.03.26.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Dec 2023 03:26:53 -0800 (PST) Message-ID: Date: Mon, 18 Dec 2023 19:26:47 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/6] mm/zswap: directly use percpu mutex and buffer in load/store Content-Language: en-US To: Yosry Ahmed Cc: Seth Jennings , Dan Streetman , Chris Li , Nhat Pham , Vitaly Wool , Andrew Morton , Johannes Weiner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chris Li References: <20231213-zswap-dstmem-v2-0-daa5d9ae41a7@bytedance.com> <20231213-zswap-dstmem-v2-6-daa5d9ae41a7@bytedance.com> From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 038F6A0008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: jsmkcjdoarsu3d18y58fcebqf9akkc6o X-HE-Tag: 1702898814-454402 X-HE-Meta: U2FsdGVkX1/G//7tlS+ZaEzd4+xNpW7UaBCp5Wt7cTmqzEpxm9W7aSWHHoPBFgpAQQGEhNNPs0DsZZb6MyJlpcGDZvUAqR4rvsZqBuE4ckltH+XDcC8tDxMQx0HOoEoLb4/L8Ne8o9ukc6NWanbc4SjqKiu398yVeSoreSUdjfQlaoJ5bxrShxxLzvl0iC9Fn/aMDrwG6X2dvYaoVw7H1bCwBy9Vi3Q8e/pyCJssTzL/ug0BARHCVO6FIaSbExNGhvfIrBEA5PcjbwLzAvjjpgM/9v2//tOB6X2Ke/MpeERbavSmfoOBRvvNPJcJJTFAwUjexh9los9CsTyXJSnRPbHiOLWUHqzcZ2QAeq+vqaYclQTl94MTD4JiBrDv7wdtNDMDVi1YQmMt4ZzA7ivMpmzdWa30F2lPTsT0Ua2zomsowcs9lz66gMZuz/tTfcQ72P9n4M2lB6YAXoHhWBngb79tXYICa/46fCjpk/If1eMtsRVjQoraeR1nfeykDRy3wk5z67BAV3XQ74AVh/UXO7I5mjE3nyxYTOp515JbEa5Xx2hLQNKJT5RT3OMGePWKeG5pA0tAcXRwo21lo0BEvv6pqo7qHmob+A/15j1QE+qRWIaoMTfCkYyAJ0QVflZezrquRz6XZIOMYRvax7xyNisgLRzvCY9wmghK6CT5dvlaAsaMBcMTHGYRYuKohXfq1cA7yNeqgBO8cLsfP6QpcdiHRxRw4cA8TS8qgdqxkoBC5jkCMtFzzcnyqLESbC6OTTmgVgLJqmyydhkOzmvbSwkiR6VhVU9STqjhmWxycT74SSYjAgVx9nRpGVMSdwfa8oCxUFWjG4Mvlhh/3W60KajC6mqEgb9ASyvhwGcxeCc1Staq37WJ0xtop3RBX2iauHZj6USYk5YZ7CAZesbK7w2/CoPxIZwsREd+NCf2d0X2yXRXgAlnzgEqclR8UTOjZjQGaKAVTiKsHlCmYBF yi0IH2u6 NJfsInNEe0qR6YpnCagTeU/q/2yrKkQdbw62bKiuDFs8rLkGUegqftsw5doxtbe4ZZOaGlzpAd/ycjRJ13T2sc55QAMQmckdEiJaT733gK8NWJLfCXBVnYo0FYy8iPM2Pl7bYmR9+o8X7EA1umYfOYj4lKE6p99Wu6moucTvqyttFdHi+UoKUe9S99KHzhKJ9TLs1SMJumKBnoraK3Tq5q5m1PZTroURUqJ78MjEXgIJ1lI4VV8s2CYgtH8KkT8OHpuyEXrDWS79ii+J0eQhCH1gDzNalomht5nDekQxbbx9DHEVHyqZjdBTU6s4v5fvIGckCAoTJAMM809bzWCNS8eWyc2S+jx23Oji1utr77z9Elx+PKvIgZqRI1fA7GS3p1NIoMe5wQXYDtGLxbBC06MQXF/i9rXj6MzMqJ7c7adHIsyAoaVm/IFkc/zo8GtOyDGjo8m/nL5YAZmANY9lK+Ugviw== 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 2023/12/18 17:37, Yosry Ahmed wrote: > On Mon, Dec 18, 2023 at 12:22 AM Chengming Zhou > wrote: >> >> Since the introduce of reusing the dstmem in the load path, it seems >> confusing that we are now using acomp_ctx->dstmem and acomp_ctx->mutex >> now for purposes other than what the naming suggests. >> >> Yosry suggested removing these two fields from acomp_ctx, and directly >> using zswap_dstmem and zswap_mutex in both the load and store paths, >> rename them, and add proper comments above their definitions that they >> are for generic percpu buffering on the load and store paths. >> >> So this patch remove dstmem and mutex from acomp_ctx, and rename the >> zswap_dstmem to zswap_buffer, using the percpu mutex and buffer on >> the load and store paths. And refactor out __zswap_store() to only >> include the compress & store, since I found zswap_store() is too long. > > I am not sure refactoring out __zswap_store() is useful to be honest, > but I am not objecting to it, it mirrors __zswap_load() in a sense. Yes, it mirrors __zswap_load() and only includes compress and store. And it makes easy for me to only concentrate on __zswap_store/load() when renaming the percpu buffers and mutex. But if anyone has objection, I can drop it. > However, if you want to do so, please do it in a separate patch from > renaming the percpu buffers and mutex. This will make reviewing easier > (and make my Suggested-by correctly scoped). Right, will do. > > Also, any reason why raw_smp_processor_id() is used here instead of > smp_processor_id()? > Here we don't need the CPU id stable, since we only need to pick one CPU and use the mutex to serialize. And from the comments below in , WARN would happen if we use smp_processor_id() here without other helpers. * The CPU id is stable when: * * - IRQs are disabled; * - preemption is disabled; * - the task is CPU affine. * When CONFIG_DEBUG_PREEMPT; we verify these assumption and WARN * when smp_processor_id() is used when the CPU id is not stable. Thanks!