Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp284239pxb; Wed, 22 Sep 2021 23:03:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdai0msNO/aIMaBVuZwJtXKM2/7z/Q8ruen5DK0lD/EZvUT9tA//RPRUecz6/9EUz6C0/o X-Received: by 2002:a6b:4f04:: with SMTP id d4mr2329114iob.95.1632377020521; Wed, 22 Sep 2021 23:03:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632377020; cv=none; d=google.com; s=arc-20160816; b=x5OOqO+1XsO91u4n+C+oIG8ofuggbXKxUCbpDSfUVW6HpDyi+RNpWm4mbBI32nd4uu F4MNwiLpsvx+YydhYankhYj+0lQYr3q0NvyEYqCeMfE0dJixxCedyQBcY89Kpj7q18C1 pB/MdSvlXWnNlacCBGr97rAm63RNOZIYpT0OUe8FFOeYMSavH6McsqmKAFQ9Su0aKbRx xJh+8KucBxQvh332zCDBCVAMtvr3lj+HntCS2G5o3/cbyIUd/eRyzwneY6CWtK1QVw4D I9y5NppZ0Y6XglCDQ6+hnXtaKyPKJ2aYupYijEhlucUBD9uTACKKGH98x2PLUCmivoW1 tCMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=Zw2o7pLl/QgjsQpgLLuvVSe64sAISOQHw3h2WR6yjQk=; b=oMY0ywvvwW24QhvsOecKLytrJJE1/sdeKQJnEpOqQAw26w97c/hdwijaQaUInYB+ho u3JlhO3itfpqmx7xege+9SV7v19idcUIAWBrAz33OFjmjvrGSGrz/4kGmrj+R0YD9El3 Yb47H9H6GMIocpxw8wWeNtqqUfP5jQKzika9c/xf5Jri9RVlsKZBHuST/tJ3dIuOFNdF LE+E0+jnu9LZIV2oPLxBKTcuvkcn+PhNHqfz2MAzo9WPn/xreRFP2/Ce4pi4BeAB1+WH BV7PsFZ8GVjSDDOXV5ChkT1OZIqGisFN8Dw1WrQhAW5NV+yzqHGom5cXX7ZKsac94Kk1 Y05Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=YmrdbCgZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y203si7127136iof.46.2021.09.22.23.03.27; Wed, 22 Sep 2021 23:03:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=YmrdbCgZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239248AbhIWGDm (ORCPT + 99 others); Thu, 23 Sep 2021 02:03:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239208AbhIWGDl (ORCPT ); Thu, 23 Sep 2021 02:03:41 -0400 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B8B0C061574; Wed, 22 Sep 2021 23:02:10 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id y5so866611pll.3; Wed, 22 Sep 2021 23:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Zw2o7pLl/QgjsQpgLLuvVSe64sAISOQHw3h2WR6yjQk=; b=YmrdbCgZ5+SlGb8KK0B/yBW6+YTD/8AJ0qHvS0dVxY3r6uXN0Z3ErPcTpp8EKWWPmq ESDhHDsqzUSDa+DkDYb6M63ddP8jbFKJ8AosUi+95ZHXJo6AF5pFe0GzqG1VXiIwvzvh kP2ul/G/A7yBkGlAuP0gvuJmeuBSEXzDu6OqaEh4SPn8K/IChtRG7obUOp6Zod/9L8QV wfxpJGYEsa6OwIbWMk4u7HavIfIlVMHraUclb0KVbd9Nzrb77zWWJ78mBWSM2n2m+Xd3 fzneuNQz4ZjDmkOos4+AOx8GcYkxhHOtXde7xiA8T40BJxbIaJIWStMnGpBc07bu5oF2 7vkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=Zw2o7pLl/QgjsQpgLLuvVSe64sAISOQHw3h2WR6yjQk=; b=ddxDq7JfOUvPQGjG3B/1vpl+8aNJclCm3gj384jPXQtvFrVZLbUiYOwgBCbCazGcm/ PxJk+N1+nkDDvctttL0qsq5F5F9sGF9s+eHYu+hz7EDPWMM/h23ULtZhfVqoYYgaI4wD ZT4wFbt4HYeIX6aJJBBMf6jeZfYg3Z0glrFyKQ4QGfywMFF/yAOK7/k7pbmGIJbZKSg1 UhkPr9W1yO651sdy/PRzTQcmuS8i/fsH9KbqGmuBIxXru7txbMwfR4QQQe3yLGLv/cY4 92EojSSyAu1SS3EntcYm2SgbgFQXznHrMTHDpTNKPDkmPYIaC69/5aesIpMnNuN47Q9g I4Dg== X-Gm-Message-State: AOAM531dYO+kGqflExtzQWoL1wq9C3PX/XgKj3+k3/vv2J5N1CVlUqRf d1azhYIBBUAQA28jtyUMSokLMZcTO1E= X-Received: by 2002:a17:903:244e:b0:13c:802d:92c with SMTP id l14-20020a170903244e00b0013c802d092cmr2317288pls.78.1632376929725; Wed, 22 Sep 2021 23:02:09 -0700 (PDT) Received: from google.com ([2620:15c:211:201:6a2a:9e3c:d2c:e8bc]) by smtp.gmail.com with ESMTPSA id s65sm4199790pfc.139.2021.09.22.23.02.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 23:02:09 -0700 (PDT) Sender: Minchan Kim Date: Wed, 22 Sep 2021 23:02:07 -0700 From: Minchan Kim To: Brian Geffon Cc: Andrew Morton , Nitin Gupta , Sergey Senozhatsky , Jonathan Corbet , LKML , linux-doc@vger.kernel.org, linux-block@vger.kernel.org, Suleiman Souhlal , Jesse Barnes Subject: Re: [PATCH v3] zram: Introduce an aged idle interface Message-ID: References: <20210917210640.214211-1-bgeffon@google.com> <20210921194336.947226-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Brian, On Wed, Sep 22, 2021 at 08:42:44PM -0400, Brian Geffon wrote: > Hi Minchan, > Thank you for taking a look. I'm happy to make that change, but I > personally cannot see why userspace would want to do something like > idle pages older than "0x3C seconds" or "0o250600 seconds," it just > seems like a strange way to represent seconds. What do you think? Kernel communty loves inline reply instead of top posting. ;-) I am not strong opinion about mutiple base support. The question just started from "what's the benefit with only 10-base support?" if we can support multiple bases with almost zero maintainace overhead. > > Brian > > On Wed, Sep 22, 2021 at 8:09 PM Minchan Kim wrote: > > > > On Tue, Sep 21, 2021 at 12:43:36PM -0700, Brian Geffon wrote: > > > This change introduces an aged idle interface to the existing > > > idle sysfs file for zram. > > > > > > When CONFIG_ZRAM_MEMORY_TRACKING is enabled the idle file > > > now also accepts an integer argument. This integer is the > > > age (in seconds) of pages to mark as idle. The idle file > > > still supports 'all' as it always has. This new approach > > > allows for much more control over which pages get marked > > > as idle. > > > > > > v2 -> v3: > > > - Correct unused variable warning when > > > CONFIG_ZRAM_MEMORY_TRACKING is not enabled. > > > v1 -> v2: > > > - Switch to using existing idle file. > > > - Dont compare ktime directly. > > > > > > Signed-off-by: Brian Geffon > > > --- > > > Documentation/admin-guide/blockdev/zram.rst | 8 +++ > > > drivers/block/zram/zram_drv.c | 60 +++++++++++++++------ > > > 2 files changed, 52 insertions(+), 16 deletions(-) > > > > > > diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst > > > index 700329d25f57..8c8a92e5c00c 100644 > > > --- a/Documentation/admin-guide/blockdev/zram.rst > > > +++ b/Documentation/admin-guide/blockdev/zram.rst > > > @@ -328,6 +328,14 @@ as idle:: > > > From now on, any pages on zram are idle pages. The idle mark > > > will be removed until someone requests access of the block. > > > IOW, unless there is access request, those pages are still idle pages. > > > +Additionally, when CONFIG_ZRAM_MEMORY_TRACKING is enabled pages can be > > > +marked as idle based on how long (in seconds) it's been since they were > > > +last accessed, in seconds:: > > > + > > > + echo 86400 > /sys/block/zramX/idle > > > + > > > +In this example all pages which haven't been accessed in more than 86400 > > > +seconds (one day) will be marked idle. > > > > > > Admin can request writeback of those idle pages at right timing via:: > > > > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > > > index fcaf2750f68f..2af5cdb8da1a 100644 > > > --- a/drivers/block/zram/zram_drv.c > > > +++ b/drivers/block/zram/zram_drv.c > > > @@ -291,22 +291,16 @@ static ssize_t mem_used_max_store(struct device *dev, > > > return len; > > > } > > > > > > -static ssize_t idle_store(struct device *dev, > > > - struct device_attribute *attr, const char *buf, size_t len) > > > +/* > > > + * Mark all pages which are older than or equal to cutoff as IDLE. > > > + * Callers should hold the zram init lock in read mode > > > + **/ > > > +static void mark_idle(struct zram *zram, ktime_t cutoff) > > > { > > > - struct zram *zram = dev_to_zram(dev); > > > + int is_idle = 1; > > > unsigned long nr_pages = zram->disksize >> PAGE_SHIFT; > > > int index; > > > > > > - if (!sysfs_streq(buf, "all")) > > > - return -EINVAL; > > > - > > > - down_read(&zram->init_lock); > > > - if (!init_done(zram)) { > > > - up_read(&zram->init_lock); > > > - return -EINVAL; > > > - } > > > - > > > for (index = 0; index < nr_pages; index++) { > > > /* > > > * Do not mark ZRAM_UNDER_WB slot as ZRAM_IDLE to close race. > > > @@ -314,14 +308,48 @@ static ssize_t idle_store(struct device *dev, > > > */ > > > zram_slot_lock(zram, index); > > > if (zram_allocated(zram, index) && > > > - !zram_test_flag(zram, index, ZRAM_UNDER_WB)) > > > - zram_set_flag(zram, index, ZRAM_IDLE); > > > + !zram_test_flag(zram, index, ZRAM_UNDER_WB)) { > > > +#ifdef CONFIG_ZRAM_MEMORY_TRACKING > > > + is_idle = (!cutoff || ktime_after(cutoff, zram->table[index].ac_time)); > > > +#endif > > > + if (is_idle) > > > + zram_set_flag(zram, index, ZRAM_IDLE); > > > + } > > > zram_slot_unlock(zram, index); > > > } > > > +} > > > > > > - up_read(&zram->init_lock); > > > +static ssize_t idle_store(struct device *dev, > > > + struct device_attribute *attr, const char *buf, size_t len) > > > +{ > > > + struct zram *zram = dev_to_zram(dev); > > > + ktime_t cutoff_time = 0; > > > + ssize_t rv = -EINVAL; > > > > > > - return len; > > > + if (!sysfs_streq(buf, "all")) { > > > +#ifdef CONFIG_ZRAM_MEMORY_TRACKING > > > + u64 age_sec; > > > + /* If it did not parse as 'all' try to treat it as an integer */ > > > + if (!kstrtoull(buf, 10, &age_sec)) > > > > nit: > > Do we need such limit base which work with only 10 base? > > Passing 0 would give more flexibility. > > > > Otherwise, looks good to me. > > > > Thanks, Brian. > > > > > + cutoff_time = ktime_sub(ktime_get_boottime(), > > > + ns_to_ktime(age_sec * NSEC_PER_SEC)); > > > + else > > > +#endif > > > + goto out; > > > + } > > > + > > > + down_read(&zram->init_lock); > > > + if (!init_done(zram)) > > > + goto out_unlock; > > > + > > > + /* A age_sec of 0 marks everything as idle, this is the "all" behavior */ > > > + mark_idle(zram, cutoff_time); > > > + rv = len; > > > + > > > +out_unlock: > > > + up_read(&zram->init_lock); > > > +out: > > > + return rv; > > > } > > > > > > #ifdef CONFIG_ZRAM_WRITEBACK > > > -- > > > 2.33.0.464.g1972c5931b-goog > > >