linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nitin Gupta <ngupta@vflare.org>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [PATCHv4 00/10] add on-demand device creation
Date: Wed, 6 May 2015 14:25:57 +0900	[thread overview]
Message-ID: <20150506052557.GA820@swordfish> (raw)
In-Reply-To: <20150506050114.GA29132@blaptop>


Hi,

On (05/06/15 14:01), Minchan Kim wrote:
> Hello Sergey,
> 
> On Mon, May 04, 2015 at 09:38:52PM +0900, Sergey Senozhatsky wrote:
> > We currently don't support zram on-demand device creation.  The only way
> > to have N zram devices is to specify num_devices module parameter (default
> > value 1).  That means that if, for some reason, at some point, user wants
> > to have N + 1 devies he/she must umount all the existing devices, unload
> > the module, load the module passing num_devices equals to N + 1.
> > 
> > This patchset introduces zram-control sysfs class, which has two sysfs
> > attrs:
> > 
> >  - zram_add     -- add a new zram device
> >  - zram_remove  -- remove a specific (device_id) zram device
> > 
> >     Usage example:
> >         # add a new specific zram device
> >         cat /sys/class/zram-control/zram_add
> >         1
> > 
> >         # remove a specific zram device
> >         echo 4 > /sys/class/zram-control/zram_remove
> 
> I just reported bug. Please handle it.

a-ha... found it:
http://lkml.iu.edu/hypermail/linux/kernel/1505.0/04389.html

will take a look. thanks!

> Other nits:
> 
> 1) How about inserting a step to reset before zram_remove?
> IOW, user should echo "1" > /sys/block/zram[0-9]*/reset before
> echo zram_id > /sys/class/zram-control/zram_remove.
> 
> Actually, I can't think any benefit other than consistency of
> zram interface but you might have.

well, I did this the way it is because there is no requirement to reset any
devices before `rmmod zram' (which eventually removes all zram devices from the
system), a set of umount-s is enough. so requiring both umount and reset before
hot_remove seems to be a bit different.

zram_remove() is called from both hot_remove and zram_exit()->destroy_devices()
(which requires reset step anyway). so I'm not sure about this change. do you
have any strong objections?


> 2) How about using hot_add/hot_remove?
> 
> /class/zram-control includes prefix zram meaning so I think
> we don't need zram prefix of the knobs. Instead, let's add
> *hot* which is more straightforward for representing *dynamic*.
> 
> What do you think about it?

ok. I can change it. I'll ask Andrew to drop the entire patch series and
will resubmit once we settle it down.

	-ss

  reply	other threads:[~2015-05-06  5:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04 12:38 [PATCHv4 00/10] add on-demand device creation Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 01/10] zram: add `compact` sysfs entry to documentation Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 02/10] zram: cosmetic ZRAM_ATTR_RO code formatting tweak Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 03/10] zram: use idr instead of `zram_devices' array Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 04/10] zram: reorganize code layout Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 05/10] zram: remove max_num_devices limitation Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 06/10] zram: report every added and removed device Sergey Senozhatsky
2015-05-04 12:38 ` [PATCHv4 07/10] zram: trivial: correct flag operations comment Sergey Senozhatsky
2015-05-04 12:39 ` [PATCHv4 08/10] zram: return zram device_id from zram_add() Sergey Senozhatsky
2015-05-04 12:39 ` [PATCHv4 09/10] zram: close race by open overriding Sergey Senozhatsky
2015-05-04 12:39 ` [PATCHv4 10/10] zram: add dynamic device add/remove functionality Sergey Senozhatsky
2015-05-06  5:01 ` [PATCHv4 00/10] add on-demand device creation Minchan Kim
2015-05-06  5:25   ` Sergey Senozhatsky [this message]
2015-05-06  6:52     ` Minchan Kim
2015-05-06  7:07     ` Sergey Senozhatsky
2015-05-06  7:28       ` Minchan Kim
2015-05-06  8:10         ` Sergey Senozhatsky
2015-05-06  8:20           ` Minchan Kim
2015-05-07  0:33             ` Sergey Senozhatsky
2015-05-07  7:41               ` Minchan Kim
2015-05-07 12:09                 ` Sergey Senozhatsky
2015-05-07 13:04                   ` Sergey Senozhatsky
2015-05-07 15:11                     ` Minchan Kim
2015-05-08  0:15                       ` Sergey Senozhatsky
2015-05-10  8:47                       ` Sergey Senozhatsky
2015-05-06  5:31 ` Sergey Senozhatsky

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=20150506052557.GA820@swordfish \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.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 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).