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 9245BC4332F for ; Fri, 11 Nov 2022 01:07:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1D096B0071; Thu, 10 Nov 2022 20:07:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA57F6B0074; Thu, 10 Nov 2022 20:07:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1F5C8E0002; Thu, 10 Nov 2022 20:07:12 -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 9F4776B0071 for ; Thu, 10 Nov 2022 20:07:12 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 761BCA07B1 for ; Fri, 11 Nov 2022 01:07:12 +0000 (UTC) X-FDA: 80119372704.10.63D2FE6 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf22.hostedemail.com (Postfix) with ESMTP id 0A313C0006 for ; Fri, 11 Nov 2022 01:07:11 +0000 (UTC) Received: by mail-pf1-f176.google.com with SMTP id g62so3570689pfb.10 for ; Thu, 10 Nov 2022 17:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=rA3+wKh3EdaWBw0rOv2qo0sGAH/sOd4ZXXqLc1LTopw=; b=DdFDHSzgzBO799XV6cwlfQyrsaUFQfKLoyLDeFNweuqt4Qrtb+nc8ghCYTIrkx/j2P PnzLO06BBVEQgEwvdzD2TWOVP2yAuC7LAtuAm6VSnPPfaK8QxytA7yv0OhxbCpBs9smZ wsyMLwblWLdjNNrI3iGJim6hgHcwgAX0vCVYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=rA3+wKh3EdaWBw0rOv2qo0sGAH/sOd4ZXXqLc1LTopw=; b=54xYf0ENkxelcHz5Smln0+V2LxLO4O8za0NbNSxPfuzRpdcnQYM3sPrGNFsUwBfpK/ SGD27SliXLJn8oOuGl84pxbwxJH9TysOvcuXfs4eEAamy0dre7i+g1oFGsykON+DWC4B Xma9ABCbZuIKzd3Ha9em1eESKu6EillYJob2UDBWxyv1SK+5WZvQ5pbHVDlC6t0Mmvfp K3qoD8Xp7dUBaSz8BGWB2KFn4oZRzSKKDCIeOi7skXG1pKRD8kwsapGQjYs+o82giEn4 2lensz09//hzRehWKGdKRXXyquc6pBLl21h3/Sxdcfv6+ctd5rDeAVQjKX51KoxykfNc UN8Q== X-Gm-Message-State: ANoB5pmajBFkK/VT667TmzHBvOvMiWTn4UTulerdH96xaO9PmBSKeMzM iN0/eefUnLNPTEiAPkdFvP+8bA== X-Google-Smtp-Source: AA0mqf4QbRuENAhj2rhhocwrW/mhpTBLaySMxyAj6wGq7XTFY5BUYUpXVNB8zenf7vDccyzsrSeWVA== X-Received: by 2002:aa7:8092:0:b0:56d:8145:3faa with SMTP id v18-20020aa78092000000b0056d81453faamr94514pff.75.1668128831068; Thu, 10 Nov 2022 17:07:11 -0800 (PST) Received: from google.com ([240f:75:7537:3187:8d55:c60d:579d:741c]) by smtp.gmail.com with ESMTPSA id nn14-20020a17090b38ce00b00213d28a6dedsm3709254pjb.13.2022.11.10.17.07.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 17:07:10 -0800 (PST) Date: Fri, 11 Nov 2022 10:07:06 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 4/9] zsmalloc: make huge class watermark zs_pool member Message-ID: References: <20221031054108.541190-1-senozhatsky@chromium.org> <20221031054108.541190-5-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668128832; a=rsa-sha256; cv=none; b=vR9i2jfjkA/PBLEqPjAT946gXkT+fGoytRj9vYIpA7gPpYtGhf/77Uod0bok9WKbbT4xN9 xxCElcZ0fSqWqFEMkbOmHEtT2h+Dknfm1XAmNOZAOgnlQr6M1elwx4jpjaIwTRf7PzUDFG LwYX5DWPlmygxFqz7emdqBTyTtM08U8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DdFDHSzg; spf=pass (imf22.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.176 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668128832; 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=rA3+wKh3EdaWBw0rOv2qo0sGAH/sOd4ZXXqLc1LTopw=; b=XrLP2amESpb3PqO4K8Wc/Fjr07c7k7QZIJ4unA0012bDHXjBQeTPc6U7o3EkBRZ+CUBv17 Bwq9OR25phr5VYbxfL8jgW0ySwQvIbxsq8wbYrnlEarF6/0pP2g85b6km0wj+gQo+bgcjD 01vXtimvB01qLl9APxcT+Nw4fhsSPeg= Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DdFDHSzg; spf=pass (imf22.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.176 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: n5ncgk87iskbc1giwngc71dr6s4fzb37 X-Rspamd-Queue-Id: 0A313C0006 X-HE-Tag: 1668128831-553846 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001566, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/11/10 14:25), Minchan Kim wrote: > On Mon, Oct 31, 2022 at 02:41:03PM +0900, Sergey Senozhatsky wrote: > > We will permit per-pool configuration of pages per-zspage value, > > which changes characteristics of the classes and moves around > > huge class size watermark. Thus huge class size needs to be > > a per-pool variable. > > I think part of code in previous patch should move here since > you are creating the feature in this patch: What do you mean? This patch - make huge_class_size a pool value - looks completely independent to me. > BTW, I am wondering we really need to jump the per-pool config > option over global general golden ratio and/or smarter approach > to optimize transparently depending on how much memory we have > wasted. I like the per-zspool value. Dynamic zspage sizing is going to be very very difficult if possible at all. With different zspage limits we create different size class clusters and we also limit huge size class watermark. So if we say, increase the zspage length value, then we have more size classes: but in order for us to actually start saving memory we need to move objects that waste memory in previous cluster configuration to new classes. It's even more complex with huge objects. When we say move huge size class watermark from 3264 to 3632 then in order to actually save memory we need to recompress huge objects and put them into size classes that are between 3264 and 3632. And that's only half. We also can lower the zspage length limit and we'll have less size classes (because they merge more) and move huge size class watermark from 3632 back to 3264. How do we handle this? I really think that per-zspool knob is the easiest way. And it doesn't block us from doing any improvements in the future.