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 A6A80C76196 for ; Tue, 28 Mar 2023 14:14:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E9376B0072; Tue, 28 Mar 2023 10:14:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2996A6B0078; Tue, 28 Mar 2023 10:14:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13A6A6B007B; Tue, 28 Mar 2023 10:14:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 006DD6B0072 for ; Tue, 28 Mar 2023 10:14:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C187EC083D for ; Tue, 28 Mar 2023 14:14:51 +0000 (UTC) X-FDA: 80618503182.09.6FF3A23 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf02.hostedemail.com (Postfix) with ESMTP id 955A080020 for ; Tue, 28 Mar 2023 14:14:49 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=KSfLRLk0; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.208.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680012889; 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=zl4pYnt0puDr71lJ58FgCz/p6pzt7waL0Z3QIQFJy8I=; b=RK/6/U/vy+5dYrvAicc5K19xiHGxZbqQSUemBtXZ/0yeKiQx0o/TtbSPZI/53bPUuScPEn Q/zI4uzGIyIiyqufIKZQLAa3g9GRi+P7Gst6zyHkQil8DYxuFX2brvC6FpUop4LiAcFGpI GxYju+WrL7KKTixki46v2qUkHjN8tyU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=KSfLRLk0; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.208.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680012889; a=rsa-sha256; cv=none; b=ckZrQbR1pkaa7l1OzysMEjITiHnoQF82NjK4LPYGc0ULLNsMfCDqblMez/Vp+BANhmu3r6 guu1o5stEm0krBeT4xFTo3YTmX8EasFceX/z/bu9G4kivKDsc5z/F/+xshiJJNd15L6/1y bKX4Ivjbu64ewD9x//zOLWgfEvTGolA= Received: by mail-ed1-f52.google.com with SMTP id x3so50256789edb.10 for ; Tue, 28 Mar 2023 07:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; t=1680012888; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=zl4pYnt0puDr71lJ58FgCz/p6pzt7waL0Z3QIQFJy8I=; b=KSfLRLk0zKBnIj8gQRXVtgd/CP6Lj80jNAGZKkVCt2HFqEAPwO27SvVtBokNR40csS 32lmJou974qZld/OMp0uJqfKQLyMJ9USGTfQdWDK2m96G5TsLIHvDyDYbubkz3oI8lU1 QSR/rRlxrDnH8HzhhfNS/5UfGUisrwhTxL/yoLLXRxnVl46P5gAMVeak/JiMJNoj7Wqz b/3/2ju4XoJ58RCHi/P2VRhL/ck3IcZFEciZMsaITvauPJYq2r/fseXrZlZEXmyHsPp+ +o+cQLvMrUdoW5vts/3glJsq2B/NoATv0B0xZpzP1cjxqfn1A4xIHd17i9wLXv7ca/XS Xj1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680012888; h=in-reply-to:content-transfer-encoding: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=zl4pYnt0puDr71lJ58FgCz/p6pzt7waL0Z3QIQFJy8I=; b=SkxHjAj+4WOrtMPAiBtMFK2G1SK0bupemQERdRR5GC1ov7/bzT+e+XFux9VY5dyyDT P5NER0Nz5kZ8KqAL8LdRe9zKjYGk4DtMYaqXUN7Mv1N2KksKLqxmlfGwCrdvfTMHwifI ITPUDfaZHDTy2fFY28BrO2wE0PMcprP2GeICQAkVTYUfVLxSAyS14JnZP4N1et26u6On M6/Q/IX6H7eJGfDp0a7cnAYIzHs54SXjGv53EypRaF/XdyzvKMOCNdCQCVsjrQPpUtkw qQaQkuuM8KZkp01yeSsAVrwVv/4wU0wtNToEgdbYisBWBVLePmj5NVl3DxljtwnT7igi FB/Q== X-Gm-Message-State: AAQBX9dmkGFfZYGiIbZTOu+XIrdCGb6ZECgyB5IgfQZMwRj34G29LegB TvOnYg48WMLWZ8dRiykSNBAohA== X-Google-Smtp-Source: AKy350ZG/O8+099MsVkPNv2gV5VkIGEP9/4hyYW6hlj8iERep4oxXhYdHz5u8l3a5vZ6u1S05cIH3g== X-Received: by 2002:aa7:d758:0:b0:502:233e:af49 with SMTP id a24-20020aa7d758000000b00502233eaf49mr14586671eds.4.1680012887872; Tue, 28 Mar 2023 07:14:47 -0700 (PDT) Received: from localhost ([2a02:8070:6387:ab20:5139:4abd:1194:8f0e]) by smtp.gmail.com with ESMTPSA id xi3-20020a170906dac300b009445d6213c0sm2864904ejb.75.2023.03.28.07.14.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Mar 2023 07:14:47 -0700 (PDT) Date: Tue, 28 Mar 2023 10:14:46 -0400 From: Johannes Weiner To: Yosry Ahmed Cc: "Huang, Ying" , Chris Li , lsf-pc@lists.linux-foundation.org, Linux-MM , Michal Hocko , Shakeel Butt , David Rientjes , Hugh Dickins , Seth Jennings , Dan Streetman , Vitaly Wool , Yang Shi , Peter Xu , Minchan Kim , Andrew Morton , Aneesh Kumar K V , Michal Hocko , Wei Xu Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap Message-ID: References: <87sfduri1j.fsf@yhuang6-desk2.ccr.corp.intel.com> <87edpbq96g.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzz1pfb3.fsf@yhuang6-desk2.ccr.corp.intel.com> <87fs9ppdhz.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 955A080020 X-Stat-Signature: ctumfz565gj3hiku51g1b3mod5th81h6 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1680012889-849301 X-HE-Meta: U2FsdGVkX18SGj9nRzqLRokHZCsCTBQaui4XS6C6vkuBEe3cd/NVRV8RRdDI0LkRGi4AruHBHCapkwG401MEspesyOyvXLRqdT1wOjDk20pVGnL8nrhQ4niNNgyMPJwbprAMi03us9zoM9t5HVoPRUStumCt08dywiy+dPlvP70iX+PghsKiTb3mfe3vW0E8maAYkERJOPLeaAGy3QdDO2Ba1OzqcO0UtyFA305jd02gUnXvRH8T5Li+TGAWGIRE8IWkcNog73e/imd4ROP3GGrZ8n/KYa5o2ZocmI7KqsQxrNeVBHY7EeI85BRWCIwx8yXuFa+5F4wCtINVKbgvih3263Lo2XjxNkV5WoVhGyQpgmhz4xjM069SwkBB+ug92eRd8XEsPvUjyg5nC1a9Qaw6nTSH9tBFbQuQQDnLKpqETEOYNItxw8UfReoQMGtcqYncilAiZ6NoSu7c7+juWEnVYEz9BRl/lOlc4+8InepK/tk5tmQ5M9Q0HR7G3NNBOHE+J7H9oeDIY0MDFi1YGriXmXCjcJHOslJ1wqiOWLWg32yZNDYSnbUDPIwgNOCwHVrP70Hive50dcGL7ibeSWUMAoh3zHxsLRcyvcg+bYlUEWPq8CgBuXKEaTrNYbrzhyrwlH/IYwpauEgvvyfhgaUcQnAOfBedLN3ev847RV9ARluCQ3OYNIQH5pgSRBmaCrd70RWJP16UHk6/YYbb6xS5roW/0H82CuobOjdtfRLdiAfngpdblnyNTEfGDBuPHbDgOXYcosbFi1IrQgLWF//EDpTqxx4DWAmQt5C2pQ2lXg99H1Xb6IXKuoTGPGsfBtbgXXGuFh7wNAtOGoceRlzcNf1CkiqjEY3SypkU/o2P5G7DPuRId5/RZISGb0LYOr2U9Br9Mr0jjc5SciS4JcBGbJ1A9fCtbON93tt2rg/9BAFpWNeH/a4S7JZ+gJoKNCf0V8OK5QeFnku4h86 d2kSvja8 1hHeA2BZyxuYtnInEcMI5mQ6xsx5Mv6BxX7Tim7anViovaZelrtcuykGz99BSd38JfRek744wzUsAghV5GtXRy0E5DePr6CJKhBUElnAE1AK46zKTHdlTTFCV7gyFdamMWkOwA8fMhuFodTs7ES/zOHqjVRYBY/WAKSyiSJNWAnSfDJvEZMnhUOd1jnKzZiqeYrHc540RWNcxAAY5H0niiSndIZzaM/eCm2DELbJO3zEHsTiYzXSyyKXs18GUHd1rxrIgCEyr8SVZtYhq9/2t7nh8KLCKeiBjG4AhIGwe8fJPszAnyVtwA8mdessVN3P6UWWFLG1lrHCYKaiTHcBAUHA5pu9L2zF581E6ClH8RqVbwbBhf6LyHLDQHE7rXwFY0WehFCvjRxNo9NXc6yxDxqOuLvYEKJZg9gimPxcje/3Z300GVww6mJX29/sEwYIOGc/+6ZDPRJIUtslCMkpqW5D4IuWbhETAKNhDRnm7j/FTatI= 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: On Tue, Mar 28, 2023 at 12:59:31AM -0700, Yosry Ahmed wrote: > On Tue, Mar 28, 2023 at 12:01 AM Huang, Ying wrote: > > Yosry Ahmed writes: > > > We also have to unnecessarily limit the size of zswap with the size of > > > this fake swapfile. > > > > I guess you need to limit the size of zswap anyway, because you need to > > decide when to start to writeback or moving to the lower tiers. > > zswap has a knob to limit its size, but based on the actual memory > usage of zswap (i.e the size of compressed pages). There is ongoing > work as well to autotune this if I remember correctly. Having to deal > with both the limit on compressed memory and the limited on the > uncompressed size of swapped pages is cumbersome. Again, we already > have this behavior today, but the initial swap_desc proposal aimed to > avoid it. Right. The optimal size of the zswap pool on top of a swapfile depends on the size and compressibility of the warm set of the workload: data that's too cold for regular memory yet too hot for swap. This is obviously highly dynamic, and even varies over time within individual jobs. With this proposal, we'd have to provision a static swap map for the highest expected offloading rate and compression ratio on every host of a shared pool. On 256G machines that would put the fixed overhead at a couple of hundred MB if I counted right. Not the end of the world I guess. And I agree it would make for simpler initial patches. OTOH, it would add more quirks to the swap code instead of cleaning it up. And given how common compressed memory setups are nowadays, it still feels like it's trading off too far in favor of regular swap setups at the expense of compression. So it wouldn't be my first preference. But it sounds workable.