lkml.org 
[lkml]   [2014]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: zram: device management utility needed
On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> Hello,
>
> Not so long ago Timofey has reached both util-linux[1] and kernel[2]
> contributors with intention to make zram device management too. I think
> the proposal is good, and there should be distribution independent tool
> like that. Also such command fits fairly well to a scope of util-linux
> package. But a tool is only as good as kernel support of it is. This
> mail is a bit about both.
>
> Existing proposal for zramctl[3], wrote by Timofey, does what I would
> call great starting point. It can resize zram device, select algorithm,
> and set number of threads. Unfortunately it cannot create or remove zram
> devices.
>
> The zram devices are not created by any sort of equipment appearing in a
> bus so an method of creating new or removing existing devices will be
> needed. When the zram module is loaded it should create
> /dev/zram-control device, that responds to ioctl() calls[4]. The calls
> could be similar with /dev/loop-control[5], that allow adding or removing
> specified device, and discover adding a free device.

Normally, dynamic management is good to have, I think but I didn't hear
strong requirement for that until now.
Why don't you change num_device param at module loading time?
I'd like to hear real scenario from whom are about to using that faeture
right now and what's the problem with num_device param.


>
> This proposal would not affect the current initialization of the zram
> devices[6]. It would be an addition to manage zram devices after kernel
> module is loaded, of course each device separately and individually. At
> the moment adding a device requires removing the existing devices[7],
> which can mean data loss, and at least unnecessary hassle when performing
> a device addition task.

If there is any holder of device, we shouldn't destroy the device.
It's doable.

>
> But before getting too exited and asking for ioctl() allocation, or
> thinking too much about code, does an overall plan like this make sense?
> Is there an alternative that would be better than /dev/zram-control +
> ioctl()'s? Any other comments, better proposal, and so on?
>
> Finally, Hats off to Timofey, you got the ball rolling getting the zram
> devices being dynamic someday in future.

I vote such standard tool to control each zram device's property but need
more thinking about dynamic device adding/removal.

>
> [1] http://www.spinics.net/lists/util-linux-ng/index.html#09781
> [2] https://lkml.org/lkml/2014/7/17/272
> [3] http://www.spinics.net/lists/util-linux-ng/msg09900.html
> [4] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/ioctl-number.txt?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8
> [5] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8#n1757
> [6] such as: modprobe zram num_devices=4
> [7] requires 'rmmod zram' which is not possible if any zram device is busy
>
> --
> Sami Kerola
> http://www.iki.fi/kerolasa/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
Kind regards,
Minchan Kim


\
 
 \ /
  Last update: 2014-08-05 04:41    [W:0.215 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site