All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] zram: user per-cpu compression streams
Date: Tue, 3 May 2016 15:53:10 +0900	[thread overview]
Message-ID: <20160503065310.GD25545@swordfish> (raw)
In-Reply-To: <20160503050348.GA17316@bbox>

On (05/03/16 14:03), Minchan Kim wrote:
> > will io_stat node work for you?
> 
> Firstly, I thought io_stat would be better. However, on second thought,
> I want to withdraw.
> 
> I think io_stat should go away.
> 
>         failed_read
>         failed_write
>         invalid_io
> 
> I think Above things are really unneeded. If something is fail, upper
> class on top of zram, for example, FSes or Swap should emit the warning.
> So, I don't think we need to maintain it in zram layer.
> 
>         notify_free
> 
> It's kins of discard command for the point of block device so I think
> general block should take care of it like read and write. If block will
> do it, remained thing about notify_free is only zram_slot_free_notify
> so I think we can move it from io_stat to mm_stat because it's related
> to memory, not block I/O.
> 
> With hoping with above things, I suggest let's not add anything to
> io_stat any more from now on and let's remove it sometime.
> Instead of it, let's add new dup stat.
> 
> What do you think about it?

I agree and it's true that we export a number of senseless and useless
stats (well, to most of the users). what's your plan regarding the
num_recompress file? is it guaranteed to go away once we convince ourselves
that per-cpu streams are fine (1 or 2 years later) or will it stay? if it's
100% 'temporal' then _probably_ we can instead add a per-device
/sys/.../zramID/debug_file  (or similar name), document it as
  "IT WILL NEVER BE DOCUMENTED, IT WILL NEVER BE STABLE, DON'T EVER USE IT"
and export there anything we want anytime we want. or is it too childish?

	-ss

      reply	other threads:[~2016-05-03  6:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 16:17 [PATCH 0/2] zram: switch to per-cpu compression streams Sergey Senozhatsky
2016-04-28 16:17 ` [PATCH 1/2] zsmalloc: require GFP in zs_malloc() Sergey Senozhatsky
2016-04-29  5:44   ` Minchan Kim
2016-04-29  7:30     ` Sergey Senozhatsky
2016-04-28 16:17 ` [PATCH 2/2] zram: user per-cpu compression streams Sergey Senozhatsky
2016-05-02  6:23   ` Minchan Kim
2016-05-02  7:25     ` Sergey Senozhatsky
2016-05-02  8:06       ` Sergey Senozhatsky
2016-05-03  5:23         ` Minchan Kim
2016-05-03  5:40           ` Minchan Kim
2016-05-03  5:57             ` Sergey Senozhatsky
2016-05-03  6:19               ` Minchan Kim
2016-05-03  7:01                 ` Sergey Senozhatsky
2016-05-03  5:44           ` Sergey Senozhatsky
2016-05-02  8:28       ` Minchan Kim
2016-05-02  9:21         ` Sergey Senozhatsky
2016-05-03  1:40           ` Minchan Kim
2016-05-03  1:53             ` Sergey Senozhatsky
2016-05-03  2:20               ` Minchan Kim
2016-05-03  2:30                 ` Sergey Senozhatsky
2016-05-03  4:29                   ` Sergey Senozhatsky
2016-05-03  5:03                     ` Minchan Kim
2016-05-03  6:53                       ` Sergey Senozhatsky [this message]

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=20160503065310.GD25545@swordfish \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.