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 54166C4167B for ; Fri, 8 Dec 2023 16:35:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5CE26B008A; Fri, 8 Dec 2023 11:35:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0C036B008C; Fri, 8 Dec 2023 11:35:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4F16B0092; Fri, 8 Dec 2023 11:35:00 -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 BAB5F6B008A for ; Fri, 8 Dec 2023 11:35:00 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8CAB91C088A for ; Fri, 8 Dec 2023 16:35:00 +0000 (UTC) X-FDA: 81544200360.06.AFDC244 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf12.hostedemail.com (Postfix) with ESMTP id 6F4A94001A for ; Fri, 8 Dec 2023 16:34:58 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b="uSD/YhD1"; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf12.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.169 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702053298; 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=/2+AmVgLDfypwxW3Bljg7Nlcki/DDdvlAbwDqkv78IU=; b=N2l1OlAf+AhuWBwAIGmS/MBgTm4CcrjfwrIbutAzAn+wFVFasR6LKSO05rGXH66K74LGeF RDXWV/0UW2CP+vV51lejYpGQkctrrwEti1Noiy/UjTyQWl1nfZAu0CbROZWaTudStQbu1K hKNoupum6grcgFc9LIUc67DuDFbqrzg= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b="uSD/YhD1"; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf12.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.169 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702053298; a=rsa-sha256; cv=none; b=qKIisgXIIpRCZRoEBrvWaUQihzgwLVm0BI9zAbXnCXoy4q9h0vaxpUSsmsaswVSgaVRBHN hNC0dL3QHlyw1hqwjLzvZ4MNaRqIYih4NYNd67XwmaYuCPfvdxxO1rNtKiN6mxVtJKzVrY YkjO6IqwbmReygc0IR7Bj6a8JJ+PEoU= Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-77f44cd99c6so117489285a.0 for ; Fri, 08 Dec 2023 08:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1702053297; x=1702658097; darn=kvack.org; 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=/2+AmVgLDfypwxW3Bljg7Nlcki/DDdvlAbwDqkv78IU=; b=uSD/YhD10GUCH7mFLdllHe6mxvOdUNGdJL/IALe+DR1pnyr6oli25XdT7IWE1biLuH /6V9x9AsCf9eT4STI288WMOTHYwWn0GSZINnoFr17SHiM5dkniH4ZqXCo7fDFDcRg9aW en4AVcaJZlOQA8dXrXiz8fp4RbE1Ce/EZtmEO8U5pgCjxYYN0buvZc/u+pPoo1GepIDR 14JtVTj4seB2QyNKnlDNf78MCXISv+j954UtAGMWienRnrXnFQmJq3x/a946TQlq3rnG PnQaar3Spb3JHcSB7iPbOrqjo03bDjnS+8vWP+YVImExlfVKCH9WKt2kuRejF7FoK/mR Buuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702053297; x=1702658097; 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=/2+AmVgLDfypwxW3Bljg7Nlcki/DDdvlAbwDqkv78IU=; b=tUmTHMEHNzBongPOT+rrB17Vzmb0lMou0lY5O0tv6nhIua3Mjsa6eet0BoMBzdjIW6 3RUT3AtxJFytBLExt0O7vcFFCXza4BuQFSSCPdlMVaFty487SmQkZhlchYY7dhLu19V8 +mSSxWwn7BAuMIAA7Gc6OijRD/3srWK6wSegiiWh4yKz1uDcLDCv1fJhxTvZgJIm5FPm 6Nrgim62n2Xa2PLHMwhv0rpywB8Le3QmMyicqfWctEwfr2PYSXPhn5AcmMRPKYAAMSG+ FmtjY4AAxtaTmx4wvVG32k9bi7zERUExlajhAFBWcwezY+cenyMFmSftCH3BQpoNhbCF QsUQ== X-Gm-Message-State: AOJu0YyURCpQBYVof/uc57QG06NracquBqSN+e8yuKlfonUoXAib8XnG PVYf2FCu8J5GO7OAg3jR7ODoLQ== X-Google-Smtp-Source: AGHT+IFe1Xg0qwccEDuPPnzdLWZ8EYqrBETcx+Lf9yWWCpT5/NmbxdDEr56PRuW1STtBLXxRVw3QKg== X-Received: by 2002:a05:620a:2187:b0:77e:ffb5:271a with SMTP id g7-20020a05620a218700b0077effb5271amr1661333qka.44.1702053297239; Fri, 08 Dec 2023 08:34:57 -0800 (PST) Received: from localhost (2603-7000-0c01-2716-da5e-d3ff-fee7-26e7.res6.spectrum.com. [2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id rc3-20020a05620a8d8300b0077dc7a029bfsm802254qkn.100.2023.12.08.08.34.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 08:34:56 -0800 (PST) Date: Fri, 8 Dec 2023 11:34:51 -0500 From: Johannes Weiner To: Yosry Ahmed Cc: Nhat Pham , Chris Li , akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, cerasuolodomenico@gmail.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 Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling Message-ID: <20231208163451.GA880930@cmpxchg.org> References: <20231207192406.3809579-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6F4A94001A X-Stat-Signature: 5uhysw7bcnjpjwm1yzukq4q398eifous X-HE-Tag: 1702053298-974121 X-HE-Meta: U2FsdGVkX19jh5eLP5OqMNwsqxVGrxBNvjgAOJ3qs29IAysXp2F4B5l2W8ZtrrCX8eOoaY5CvRhjZM0z5UITZAFL0/JAY8h0JWZLP+QWW1GXFIhIvdZZE2zHDboSEKyu145689c5V22Wov5NrWDIS56dFzY1Vo/dX/rD5gx2RhgS1kTGAGskA4o3SsWaUKUBOD0ZBDj8+FgRTSnzn9r/ji+sbfs/63MpinCUMLDZj691iDakq33BwpEPn5HZkd9d2p4lQPsKgK5l1t0xVHFD1m/sa6locrpkVPD4nSBz+sXMYpVA5yMS5xhQNBCyw1df3NuHvGpCxsWfQQ2V87pFIJFDZmijbVwPRcRKKQbtoSA6YojVoXc6yKYiBoBxNCcQrXLUHOhhxDu0SlBPqpd2joKkoWqwqjxT9yb4T5BeI33AlPMEzcUby75WI9i/9b6z+wTJjjqerTEFEhRl/l3AOQiAJGDO+PvKeE3EqnQ5naXyVM00XzibdI1wUVBAykL7tPOkPttNvLwLCXjLAyxtcX3i+ISeq/jDXwLpfKZmMw+ILVuP7IZudeKAomlzKrivh6hUjD7wDNt9W5RJ+jQQwRTJ3Yc4DG1AcQ9ubGcCSS/5vDeGQFBvTH8vzgA0sPH2a2zUAs7GDdZjcUmZkZy2/lLwKekbIiGOx1mAhlkLIWWbilZk8FFlono1ddy9usdRSjBI0JcFEz0El5K4MyismivWYyzftzmCd574ocXEofAU52Tu1cx59jtd//wejA6bKT7UBOpBKKRf5wXr/itsyOWVWC8f+Jv0U/5xBc0bkvGl0ejeqDmyTWWW0QfWlutKD7tP6AxrBhpewknSvh2wGTWmGG7ewXKd1+FA3A5rDr1BB3JRBsGzwjkGKB5YsruKP12I6e4zIEH6EjseprFcEwQAh2vE9dJ7J0CnFBuQ5IdJiyKjkP0eEVTQC21C5pvit+Cg9rhhdULwmlBJop8 9hh4r3r1 2N4JRFXuVjENTpqx4JPereQo4N1sFfjmGkqmBDfWUbMzfTB3uIUDCYcKkbeOjJYXPGI53t1XEPAODEPmfaLlytVgzXSK2mHDI1iSN3tFf9JIIL3WuHJ4AzPDgYJUcF8nmff4Up6ivGcO7fjj3yR8GxLHIJNIPB0tbdNTDtXRNoGklB2n6FWJ1+b94L6qomXKmk+2d9/Bqqs2aRU6Xh+J9q6asxrDXWYWqnZldTKX91p+2ABkiWe4xqcpNm23ECvpqslFAVtSHtPYsFf8jc545AQzVzuazWcf4l5XVUUx66jgFADVU7FRRLYEJIYRVDCIJKJkkvHJwqQSaF2uGqSKDoPI6tss1/7i1B+g4aHCmg6akuPPfziIMjqKmqM1WRH7mxf3ExOr4dxwjzJ+yT4Rej/EnnO/Ec7TkWNUWY40s/NmpfY0FI4t6YPmdxNwUI/WHHa1h2FN27F4VtcAOf0XvxvklIq2Nd+0hgjQ2PW4JP7xQELVNEPRtaLuDOHWE+9r4Do7Ho8m98F2YONofJzT85kij0Q== 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 Thu, Dec 07, 2023 at 05:12:13PM -0800, Yosry Ahmed wrote: > On Thu, Dec 7, 2023 at 5:03 PM Nhat Pham wrote: > > On Thu, Dec 7, 2023 at 4:19 PM Chris Li wrote: > > > I am wondering about the status of "memory.swap.tiers" proof of concept patch? > > > Are we still on board to have this two patch merge together somehow so > > > we can have > > > "memory.swap.tiers" == "all" and "memory.swap.tiers" == "zswap" cover the > > > memory.zswap.writeback == 1 and memory.zswap.writeback == 0 case? > > > > > > Thanks > > > > > > Chris > > > > > > > Hi Chris, > > > > I briefly summarized my recent discussion with Johannes here: > > > > https://lore.kernel.org/all/CAKEwX=NwGGRAtXoNPfq63YnNLBCF0ZDOdLVRsvzUmYhK4jxzHA@mail.gmail.com/ > > > > TL;DR is we acknowledge the potential usefulness of swap.tiers > > interface, but the use case is not quite there yet, so it does not > > make too much sense to build up that heavy machinery now. > > zswap.writeback is a more urgent need, and does not prevent swap.tiers > > if we do decide to implement it. > > I am honestly not convinced by this. There is no heavy machinery here. > The interface is more generic and extensible, but the implementation > is roughly the same. Unless we have a reason to think a swap.tiers > interface may make it difficult to extend this later or will not > support some use cases, I think we should go ahead with it. If we are > worried that "tiers" may not accurately describe future use cases, we > can be more generic and call it swap.types or something. I have to disagree. The generic swap types or tiers ideas actually look pretty far-fetched to me, and there is a lack of convincing explanation for why this is even a probable direction for swap. For example, 1. What are the other backends? Where you seem to see a multitude of backends and arbitrary hierarchies of them, I see compression and flash, and really not much else. And there is only one reasonable direction in which to combine those two. The IOPs and latencies of HDDs and network compared to modern memory sizes and compute speeds make them for the most part impractical as paging backends. So I don't see a common third swap backend, let alone a fourth or a fifth, or a multitude of meaningful ways of combining them... 2. Even if the usecases were there, enabling this would be a ton of work and open interface questions: 1) There is no generic code to transfer pages between arbitrary backends. 2) There is no accepted indirection model where a swap pte can refer to backends dynamically, in a way that makes migration feasible at scale. 3) Arbitrary global strings are somewhat unlikely to be accepted as a way to configure these hierarchies. 4) Backend file paths in a global sysfs file don't work well with namespacing. The swapfile could be in a container namespace. Containers are not guaranteed to see /sys. 5) Fixed keywords like "zswap" might not be good enough - what about compression and backend parameters? None of these are insurmountable. My point is that this would be a huge amount of prerequisite code and effort for what seems would be a fringe usecase at best right now. And there could be a lot of curve balls in both the software design as well as the hardware development between now and then that could make your proposals moot. Is a per-cgroup string file really going to be the right way to configure arbitrary hierarchies if they materialize? This strikes me as premature and speculative, for what could be, some day. We don't even do it for *internal API*. There is a review rule to introduce a function in the same patch as its first caller, to make sure it's the right abstraction and a good fit for the usecase. There is no way we can have a lower bar than that for permanent ABI. The patch here integrates with what zswap is NOW and always has been: a compressing writeback cache for swap. Should multiple swap tiers overcome all the above and actually become real, this knob here would be the least of our worries. It would be easy to just ignore, automatically override, or deprecate. So I don't think you made a reasonable proposal for an alternative, or gave convincing reasons to hold off this one.