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 C757EC433FE for ; Fri, 11 Nov 2022 10:32:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 534776B0071; Fri, 11 Nov 2022 05:32:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E5026B0072; Fri, 11 Nov 2022 05:32:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FA046B0074; Fri, 11 Nov 2022 05:32:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 34D5C6B0071 for ; Fri, 11 Nov 2022 05:32:51 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0F16A404BC for ; Fri, 11 Nov 2022 10:32:51 +0000 (UTC) X-FDA: 80120798142.09.03A9E1D Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf08.hostedemail.com (Postfix) with ESMTP id 872CD16000C for ; Fri, 11 Nov 2022 10:32:50 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id c2so3906189plz.11 for ; Fri, 11 Nov 2022 02:32:50 -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=fy5PQnQnZm5cRZ5qG1YNPYJdeovnXsDVIy0x21AyY8o=; b=PH+k/rdgrWBzPBRNudaM5JiBpiCBfD1gWgQoB6IYO8qJwTyO9sNuRZ3p9yU+KQ/SoZ FCFRsX4JqsfBpgp8PWYUih886qdD7FM2MZ2DermrWmOwcSl0HxDR/H8h3KNy2S9aRkY9 TlzPYcaX1WHy+mbtF/ee/4QwZnSigSwSiYosU= 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=fy5PQnQnZm5cRZ5qG1YNPYJdeovnXsDVIy0x21AyY8o=; b=eV0/KhItTf0wnyFUhNQvTJqWogoMCki/1+nALeNTDje0U46B012soyKQT9ktQt9JTX 4K3VlHYDhwc7uoa6NuHWelcLnej/1+jdwA0QABHsGaRdtYoUkh23u8ZkSP/XBuGgqs9K ArlaSmjpI0ZenDS4dEm5UHVnnRY3P4Ex7Qgon4lig7Wd2MFmQNmpxbtWb0ERmWEXobip 7iTl6Qb3Sf9YW3mLF3cQk3IwtRQywEttfa54VLDHhsWYzJbvj3gdmFcWblQ95jIJg5jD yyA35VNzvPIZHNpClJXAxzn4CE9WpV6dEY7Uzq8DQBswHbCqIQBdP0q73yEtn3YXj7+X pr6A== X-Gm-Message-State: ANoB5plLYg5z8/w40vi2bFthcyEnhr4vb6fqQhZ64+hii42ykTs2pyoO qHT8wo+mxKVdoYAlAS+vkFjRPA== X-Google-Smtp-Source: AA0mqf49E5wRB42wtD/3QvEvnKyw6j+BzHVe45JiCWYFPzfxUPZqNAtrqGNGJyvuQCbGZuF/apG27g== X-Received: by 2002:a17:90a:73cf:b0:213:7f5:a972 with SMTP id n15-20020a17090a73cf00b0021307f5a972mr1249702pjk.159.1668162769401; Fri, 11 Nov 2022 02:32:49 -0800 (PST) Received: from google.com ([240f:75:7537:3187:8d55:c60d:579d:741c]) by smtp.gmail.com with ESMTPSA id x125-20020a626383000000b00560bb4a57f7sm1287402pfb.179.2022.11.11.02.32.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 02:32:48 -0800 (PST) Date: Fri, 11 Nov 2022 19:32:44 +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 6/9] zsmalloc: pass limit on pages per-zspage to zs_create_pool() Message-ID: References: <20221031054108.541190-1-senozhatsky@chromium.org> <20221031054108.541190-7-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=1668162770; a=rsa-sha256; cv=none; b=QYyN+DwAVKF997T+zZ8dkP6w8TfFBxkZYy4+CDtDiNGb8NRndNjhzkQaPsybqNevExu4pu SKksrgDD59tiELJS9vvM4rCuaHX128nQJobK80ro/q46bqeSks49n80AmhIzibLPpfbOPg px5k7SZK1Dc0FjmJU029jYRWAOqRQiY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="PH+k/rdg"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf08.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.178 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668162770; 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=fy5PQnQnZm5cRZ5qG1YNPYJdeovnXsDVIy0x21AyY8o=; b=k+nhrFC8Rm0Nr3JvnyA81TgHstFg4xy9Ss7CDbKF9c9S1z07ekKsW6nlthAN1ZuFn8QVCl URl8tSXyEtwfeMg6mNYkaZ+2ZRiFWREn//pyyZffILYjKGBbNjabObhgM/q0cTVPJjmot3 CJzDVnOxkGsyr3dMt44g7qbbhlzJNb8= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="PH+k/rdg"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf08.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.178 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Rspam-User: X-Stat-Signature: 6wpxzat37c8pgddfk7xo9sjcyzwg5z3h X-Rspamd-Queue-Id: 872CD16000C X-Rspamd-Server: rspam05 X-HE-Tag: 1668162770-743267 X-Bogosity: Ham, tests=bogofilter, spamicity=0.086512, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/11/10 18:10), Minchan Kim wrote: > On Mon, Oct 31, 2022 at 02:41:05PM +0900, Sergey Senozhatsky wrote: > > Allow zsmalloc pool owner to specify max number of pages > > per-zspage (during pool creation), so that different pools > > can have different characteristics. > > > > By default we pass ZS_DEFAULT_PAGES_PER_ZSPAGE which is 4 > > (matches the current order 2 zspages limit). > > How could user decide what's the best size for their workload? [..] For starters in a similar manner that I showed during our meeting. They can run tests, gather stats (zsmalloc objects distribution), analyze where most of the objects sit, how things change when we have different cluster configurations, and so on. But more importantly: they need lots of zramX mm_stat data, which is perfectly traceable and collectable during fleet A/B testing: when a number of devices get randomly assigned to different experiments and receive different zspage len configuration, which they feed to zram sysfs knobs during system startup (when init script configures zram). And then look at statistically significant improvements or regressions. This is how things done in ChromeOS and I'm sure in many other places. In this regard, finding best zspage len value is not any different from finding what is the best zram disksize, or what is the best compression algorithm. Exactly same approach - feed different configuration to devices and then analyze the data. Look at mm_stat-s before and after experiment, per device class/type. We can discuss in more details internally. > > static void zs_zpool_destroy(void *pool) > > @@ -2195,6 +2195,7 @@ static int zs_register_shrinker(struct zs_pool *pool) > > /** > > * zs_create_pool - Creates an allocation pool to work from. > > * @name: pool name to be created > > + * @num_pages: maximum number of pages per-zspage > > How about "max_page_chain:"? OK. Do you dislike idea of creating a `struct zs_tunables` which will hold all fields that we can tune? And then zsmalloc users can pass that struct (a pointer to) to zs_create_pool(). There can be various tunables. Like policy changes: do we use static zspool configuration, or a dynamic one and so on. On zram side, we can have a generic sysfs knob: allocator_tuning, which will accept named params, the same way we did it for recomp_algorithm and recompress. echo "tuneable=VAL tunealbe=VAL" > /sys/block/zramX/allocator_tuning