public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Brian Geffon <bgeffon@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Nitin Gupta <ngupta@vflare.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH] zram: Add a huge_idle writeback mode
Date: Fri, 18 Mar 2022 10:30:23 -0700	[thread overview]
Message-ID: <YjTBryFvhCZXXJ5/@google.com> (raw)
In-Reply-To: <CADyq12wQ=vGaGoqt5RXJ5aYM1tQJ2BCT8cav-ONpPrCc85q-5Q@mail.gmail.com>

On Fri, Mar 18, 2022 at 12:51:14PM -0400, Brian Geffon wrote:
> On Fri, Mar 18, 2022 at 12:41 PM Minchan Kim <minchan@kernel.org> wrote:
> >
> > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote:
> > > Today it's only possible to write back as a page, idle, or huge.
> > > A user might want to writeback pages which are huge and idle first
> > > as these idle pages do not require decompression and make a good
> > > first pass for writeback.
> >
> > Hi Brian,
> >
> > I am not sure how much the decompression overhead matter for idle pages
> > writeback since it's already *very slow* path in zram but I agree that
> > it would be a good first pass since the memory saving for huge writing
> > would be cost efficient.
> >
> > Just out of curiosity. Do you have real usecase?
> 
> Hi Minchan,
> Thank you for taking a look. When we are thinking about writeback
> we're trying to be very sensitive to our devices storage endurance,
> for this reason we will have a fairly conservative writeback limit.
> Given that, we want to make sure we're maximizing what lands on disk
> while still minimizing the refault time. We could take the approach
> where we always writeback huge pages but then we may result in very
> quick refaults which would be a huge waste of time. So idle writeback
> is a must for us and being able to writeback the pages which have
> maximum value (huge) would be very useful.

Thanks for sharing the thought. It really make sense to me and
would be great if it goes on the description.

  reply	other threads:[~2022-03-18 17:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 17:22 [PATCH] zram: Add a huge_idle writeback mode Brian Geffon
2022-03-15 17:28 ` Matthew Wilcox
2022-03-15 17:34   ` Brian Geffon
2022-03-15 17:44     ` Matthew Wilcox
2022-03-16  0:01       ` Brian Geffon
2022-03-18 16:41 ` Minchan Kim
2022-03-18 16:51   ` Brian Geffon
2022-03-18 17:30     ` Minchan Kim [this message]
2022-03-21 14:50 ` Brian Geffon
2022-03-22 21:13   ` Minchan Kim
2022-03-22 21:52     ` Brian Geffon
2022-03-22 21:58 ` [PATCH v2] " Brian Geffon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YjTBryFvhCZXXJ5/@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bgeffon@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ngupta@vflare.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox