lkml.org 
[lkml]   [2016]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] zram: user per-cpu compression streams
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

\
 
 \ /
  Last update: 2016-05-03 09:21    [W:0.973 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site