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 25872C4332F for ; Fri, 15 Dec 2023 09:19:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F03B6B0458; Fri, 15 Dec 2023 04:19:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A1796B045A; Fri, 15 Dec 2023 04:19:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FC516B0460; Fri, 15 Dec 2023 04:19:22 -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 69A5E6B0458 for ; Fri, 15 Dec 2023 04:19:22 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3FD75A087C for ; Fri, 15 Dec 2023 09:19:22 +0000 (UTC) X-FDA: 81568504164.27.0F7C8A0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf06.hostedemail.com (Postfix) with ESMTP id 3ABC518000B for ; Fri, 15 Dec 2023 09:19:20 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eOK8VFTw; spf=pass (imf06.hostedemail.com: domain of fdeutsch@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fdeutsch@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702631960; 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=LKRB2NM0clLrFwpWnoPlY4hiBNwWvNpQCg6DNVGwp2M=; b=M+7GQf9+fEZaQnuytZbHEdzKmI5s+IEIqnXkWu8oHmjsTd5vntaf1TYN4ishmgmdMB45K5 3pQT+hs40IdX8T6WjILsQE1rX4ZI1yFdURPn1+n1SLPwk9D94SzCFTyjgr3BnF70D+u1YG soQXPX+3pB14CDiOfxMZHXT3WGxEq78= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eOK8VFTw; spf=pass (imf06.hostedemail.com: domain of fdeutsch@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fdeutsch@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702631960; a=rsa-sha256; cv=none; b=4L0RlPc9GhpuHxlJ0hQPdggxSqnZV+nLbsdA3DI8TRjoxJbGDELI/ElLC7vOpemwwRkGTD RtMngQjkNUUMN3W4G5KgjWhSegW96U6Lwd7fUtpi3zehSIf33v81LJRg8lVi9EcWLdRV9M o9Wc5MVj+82P9ZDfMTr9+eVs4INSOd0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702631959; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LKRB2NM0clLrFwpWnoPlY4hiBNwWvNpQCg6DNVGwp2M=; b=eOK8VFTwwTxP+wu0/fOplAK3+SH+vBA9JzDtL5Gq9kr7ND7HawG57nybw8PA5iYsRp4ImT jj2lpLEgOMY1pltZBf40AbKbpqUTIBs/TADTQXy0d7OdBrrXDz7b8RilgS0H+mU3MGe3ni H3xo1gV9/xZe+d4xnrEprxvh4wKJeqo= Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-175-Px6kKC85MsykGCBIt4h94A-1; Fri, 15 Dec 2023 04:19:17 -0500 X-MC-Unique: Px6kKC85MsykGCBIt4h94A-1 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-5e31a4a893bso4325537b3.1 for ; Fri, 15 Dec 2023 01:19:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702631957; x=1703236757; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LKRB2NM0clLrFwpWnoPlY4hiBNwWvNpQCg6DNVGwp2M=; b=m4pk1NHgcvOP9ltF9Y5FNt8c0ji1QonOUIvPOezLjYBRspLLAZv0fEiQd2xCR0YGkI BKiwTLPd3gVOJ1EimLc2L0vD7ey5FTrb+ndcpk3ZAsff3Ux4R6VPI6wJ0Jsf1rGDtcWa Bqf5SDc65O/gK3IFVOaveQjM8zWOSS3WEJ+nrcE44Mr/Em8e/5+X6RbK3lTJaC5RNGzJ PxWC+50J9gDM8dnvvLLicXmLDKULSfkQLroS4Ctu9Dt9wAeb8XFzRLOuZyBp7VO4NtYa a817hulD2U+/Ts/B/iHpwB7oZWWljwtluoEvUr/Az77mocK33+6cgpkdzs1UtW46t8MV MkjA== X-Gm-Message-State: AOJu0YyyxJ/qIHy1ktvfsR98SmvodM2+LD5M2hi2NnWrveRNHD4TtBH8 8I9eGZUjk1Fvv6sjBWHelmScN2oypSiEdXYmn7rQSUlsOn1+GOaLhNmfpJVT4Gl9PYwN6u1/Vhl NUenyGht6rOIOCb+R/B9jWB1zQ8k= X-Received: by 2002:a25:d313:0:b0:dbc:decf:e511 with SMTP id e19-20020a25d313000000b00dbcdecfe511mr2256364ybf.6.1702631956799; Fri, 15 Dec 2023 01:19:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IEgsr17KvzqRFYZ501EKD77qh+g+rl8IJQIXIa2kWcig/qScLbnQVz0na85WhupZtpevRN1mt2Ub0PQecQ5UUU= X-Received: by 2002:a25:d313:0:b0:dbc:decf:e511 with SMTP id e19-20020a25d313000000b00dbcdecfe511mr2256360ybf.6.1702631956524; Fri, 15 Dec 2023 01:19:16 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231209034229.GA1001962@cmpxchg.org> <20231214171137.GA261942@cmpxchg.org> In-Reply-To: From: Fabian Deutsch Date: Fri, 15 Dec 2023 10:18:53 +0100 Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Chris Li Cc: Yu Zhao , Johannes Weiner , Minchan Kim , Nhat Pham , akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, cerasuolodomenico@gmail.com, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, hughd@google.com, corbet@lwn.net, konrad.wilk@oracle.com, senozhatsky@chromium.org, rppt@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, david@ixit.cz, Kairui Song , Zhongkun He X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000f3c840060c88e4f4" X-Rspamd-Queue-Id: 3ABC518000B X-Rspam-User: X-Stat-Signature: hkpfzqo9m17m1eiptu5e183spxhmttne X-Rspamd-Server: rspam01 X-HE-Tag: 1702631960-517656 X-HE-Meta: U2FsdGVkX19akoFENG9ftl5VFNekIBE6lU9XkwXnoiFx4BhDitsiemlhmnFByrz7HZwX2/gKEtp/cyLzOhxoJH5XuVGamGp0j5mhr0zV3oRlUVd1XWl+xpbWrgOiLuBDM0FwHFnUkfijF5zmqqL6Nk9K7gWbKb31to63XmoqpDiMRT8259fMtU8SUwxG2YoyFCsug+vHcBKxMNTMowrTrVroXmOzCbU0pVEffZAcj36wllIGzu9JoyJFLVB5T1AgKY2mqgT0aZXYTBxpyYP+yYlmEjwsaSuxIUZk5NUO2kmWpjGOkoUOYpBOZL6OksZ5EzC8Fal06X1iL57rOhJy1Va66/o1pe3k7T01B1zba3pauu8VGMbu4lTPQ2Y224aosxE5JRiKdiklpvAdt0Jkxgj7iJ7mrqk3Uvm2N269pCtEFb2+bBYaRKjSY3d0dYJ80/F4cznsKNGCACl1OKSCSe/Ue6uJ9XoFrLmMnBf5swOV17aCYi92zYmu6tMwyUPStBNKALiZDJmwvb7W7h6H4sVCOJ6THydXH+omgU4BbTJKUEi8ueA+r8H27PnIGL5GZJxEaHnCLQikpkH99VhIUNEpnReGz9Wht0qYMZlTyl1HNkCLJUTf2pkEDcN1w7bY1KnrLVd0Via6eLXbSiQJPwh5teG/Vlfq31Afpapc8tPfKIRO6uKgaXjIQmzO7SHg4wN7d9qrY/u0wX+PVBfljy6hkJ5hNw4erZWzR3sZ/r6y62NK9/5gkmdtvql61wv0BVrUNN1aRW77QsJ1DRD4uxiTwGO575Kh5ci4B9DqZVkJYLQwhmXOqESbZ8cuhIagOjpbK7p8nVdXR1OkNS7/FkrR9mm+uIDazIRBW9302vPLZMfW3Zm4gl3ev4RI9aiv+31yAg8GcDywQ4LZyRaQkVKk8uovu1TFjSvAaGjnJHt9DVmI/mRQ2EdV1VzzIj7IkodzPRaL+9SW5X2Oy63 6uay00mp R7oTQ3e4J1LD0kwV5LwV6TFb1nDCuKdH4DSGTImGZ+aLkpfkoMiV8n+MsvNJo6BrXeRLJFGSTYuutiCTgNc6KJvr+KSh/lbir51hU0/DqsPpaN659xgLi2NKvV9GKOqHOzOvV8nF/u4VtW4dgleK5G9aA+53ru8lzWzXFwOFHAlalkT7w+Jtk8ObqUOJRoG0Ey8L14Yb0UNKd2NuQwzLsFzzhVeKmZHly+7HoOtYgRQX/aI+nhhE6vdT0kMcCHonsNelieP1zx0YZUVfKftoScqb3aqUh3ay4Ob+wFMULiQ/kZ2WOgz6Nip55oXsTevm0C+WW7zPaviBIXfGP6lWkau5wO1tBFUYvzeVOMIwnKN2YrVfv+vweJo3gd+ajGgYcr2ba42cu+oTWPqW2De/gk52VFQwStmdDeXARX7AP0FK9wrlPWsQAvVPA/Q== 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: --000000000000f3c840060c88e4f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 15, 2023 at 12:22=E2=80=AFAM Chris Li wrote= : > > Hi Fabian, > > On Thu, Dec 14, 2023 at 10:00=E2=80=AFAM Fabian Deutsch wrote: > > > Yep - for container use-cases. > > > > Now a few thoughts in this direction: > > - With swap per cgroup you loose the big "statistical" benefit of having swap on a node level. well, it depends on the size of the cgroup (i.e. system.slice is quite large). > > Just to clarify, the "node" you mean the "node" in kubernetes sense, > which is the whole machine. In the Linux kernel MM context, the node > often refers to the NUMA memory node, that is not what you mean here, > right? Correct - I was referring to Kubernetes, and not numa nodes. > > > - With todays node level swap, and setting memory.swap.max=3D0 for all cgroups allows you toachieve a similar behavior (only opt-in cgroups will get swap). > > - the above approach however will still have a shared swap backend for all cgroups. > > Yes, the "memory.swap.tires" idea is trying to allow cgroups to select > a subset of the swap backend in a specific order. It is still in the > early stage of discussion. If you have any suggestion or feedback in > that direction, I am looking forward to hearing that. Interesting. There have been concerns to leak confidential data accidentally when it's getting written to a swap device. The other less discussed item was QoS for swap io traffic. At a first glance it seems like tires could help with the second use-case. - fabian > > Chris > --000000000000f3c840060c88e4f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 15, 2023 at 12:22=E2=80=AFAM Chris Li = <chrisl@kernel.org> wrote:>
> Hi Fabian,
>
> On Thu, Dec 14, 2023 at 10:00=E2= =80=AFAM Fabian Deutsch <fdeutsch= @redhat.com> wrote:
>
> > Yep - for container use-cas= es.
> >
> > Now a few thoughts in this direction:
>= > - With swap per cgroup you loose the big "statistical" bene= fit of having swap on a node level. well, it depends on the size of the cgr= oup (i.e. system.slice is quite large).
>
> Just to clarify, th= e "node" you mean the "node" in kubernetes sense,
&g= t; which is the whole machine. In the Linux kernel MM context, the node
= > often refers to the NUMA memory node, that is not what you mean here,<= br>> right?

Correct - I was referring to Kubernetes, and not numa= nodes.

>
> > - With todays node level swap, and setting= memory.swap.max=3D0 for all cgroups allows you toachieve a similar behavio= r (only opt-in cgroups will get swap).
> > - the above approach ho= wever will still have a shared swap backend for all cgroups.
>
>= ; Yes, the "memory.swap.tires" idea is trying to allow cgroups to= select
> a subset of the swap backend in a specific order. It is sti= ll in the
> early stage of discussion. If you have any suggestion or = feedback in
> that direction, I am looking forward to hearing that.
Interesting. There have been concerns to leak confidential data accid= entally when it's getting written to a swap device.

The other le= ss discussed item was QoS for swap io traffic.

At a first glance it = seems like tires could help with the second use-case.

- fabian
<= br>>
> Chris
>
--000000000000f3c840060c88e4f4--