linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Joey Pabalinas <joeypabalinas@gmail.com>
Subject: Re: [PATCH v3 7/7] zram: writeback throttle
Date: Thu, 29 Nov 2018 10:55:54 +0900	[thread overview]
Message-ID: <20181129015554.GC77327@google.com> (raw)
In-Reply-To: <20181128154141.d67b70957bc4833d9f0d6635@linux-foundation.org>

On Wed, Nov 28, 2018 at 03:41:41PM -0800, Andrew Morton wrote:
> On Tue, 27 Nov 2018 14:54:29 +0900 Minchan Kim <minchan@kernel.org> wrote:
> 
> > On small memory system, there are lots of write IO so if we use
> > flash device as swap, there would be serious flash wearout.
> > To overcome the problem, system developers need to design write
> > limitation strategy to guarantee flash health for entire product life.
> > 
> > This patch creates a new konb "writeback_limit" on zram. With that,
> > if current writeback IO count(/sys/block/zramX/io_stat) excceds

						   bd_stat
		
> > the limitation, zram stops further writeback until admin can reset
> > the limit.
> 
> I'm not really understanding this.  Does this only refer to suspending
> the idle page writeback feature?  Not all zram writeback, surely?

It aims for all zram writeback.

> 
> I don't think the documentation gives an administrator sufficient
> information to effectively use the feature.  Some additional discussion
> would help.  What sort of values should it be set to and why?
> 
> And what is the default setting?  And why?

Default setting is 0 so there is no limitation because we couldn't
expect user's workload of zram.

> 
> And the limit isn't persistent across reboots which makes me wonder
> whether the overall feature is particularly valuable?

Good point.
Keeping the value in persisten across reboot is userspace's role.

I will add this for admin
"
You could know how many of write happens since the system boot
via /sys/block/zramX/bd_stat's bd_writes.
If your backing device has wearout concern, you could limit the
writing via /sys/block/zramX/writeback_limit.

For instance, if the vaule you read bd_writes is 200, you could
set 300 to writeback_limit so upcomding 100 write be only allowed.
If you set the writeback_limit to lower value than current
bd_writes's value, zram allow further writeback without limit.

The value will reset when your system reboot so keeping how many
write happn until now across reboot is user's job.
"


  reply	other threads:[~2018-11-29  1:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27  5:54 [PATCH v3 0/7] zram idle page writeback Minchan Kim
2018-11-27  5:54 ` [PATCH v3 1/7] zram: fix lockdep warning of free block handling Minchan Kim
2018-11-29  2:43   ` Sergey Senozhatsky
2018-11-27  5:54 ` [PATCH v3 2/7] zram: fix double free backing device Minchan Kim
2018-11-29  2:32   ` Sergey Senozhatsky
2018-11-27  5:54 ` [PATCH v3 3/7] zram: refactoring flags and writeback stuff Minchan Kim
2018-11-27  5:54 ` [PATCH v3 4/7] zram: introduce ZRAM_IDLE flag Minchan Kim
2018-11-29  2:29   ` Sergey Senozhatsky
2018-11-27  5:54 ` [PATCH v3 5/7] zram: support idle/huge page writeback Minchan Kim
2018-11-28 23:35   ` Andrew Morton
2018-11-29  1:36     ` Minchan Kim
2018-11-27  5:54 ` [PATCH v3 6/7] zram: add bd_stat statistics Minchan Kim
2018-11-27  5:54 ` [PATCH v3 7/7] zram: writeback throttle Minchan Kim
2018-11-28 23:41   ` Andrew Morton
2018-11-29  1:55     ` Minchan Kim [this message]
2018-11-29  2:23   ` Sergey Senozhatsky
2018-12-02 23:18     ` Minchan Kim
2018-12-03  2:30       ` Sergey Senozhatsky
2018-12-03  2:41         ` Minchan Kim
2018-12-03  2:45           ` Sergey Senozhatsky
2018-11-30  4:36 ` [PATCH v3 0/7] zram idle page writeback Sergey Senozhatsky
2018-12-02 23:20   ` Minchan Kim
2018-12-02 23:28 ` Joey Pabalinas

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=20181129015554.GC77327@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=joeypabalinas@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).