From: Minchan Kim <minchan@kernel.org>
To: Karel Zak <kzak@redhat.com>
Cc: Sami Kerola <kerolasa@iki.fi>,
util-linux@vger.kernel.org,
Timofey Titovets <nefelim4ag@gmail.com>,
Nitin Gupta <ngupta@vflare.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: zram: device management utility needed
Date: Tue, 5 Aug 2014 08:12:47 +0000 [thread overview]
Message-ID: <20140805081238.GA3700@gmail.com> (raw)
In-Reply-To: <20140805070716.GB12104@x2.net.home>
On Tue, Aug 05, 2014 at 09:07:16AM +0200, Karel Zak wrote:
> On Tue, Aug 05, 2014 at 11:00:24AM +0900, Minchan Kim wrote:
> > On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> > > 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.
>
> I guess that number of zram devices will be always relatively small
> compare to /dev/loopN devices. It is not unusual that people use
> systems with more than 256 loop devs, so /dev/loop-control makes a lot
> of sense to keep the device management effective and simple.
>
> > Why don't you change num_device param at module loading time?
>
> If you have really many loopN devices than create all the nodes at
> boot time means extra overhead (allocate nodes in kernel, events to
> udev, create /dev files etc.). The ioctl LOOP_CTL_* API also provides
> LOOP_CTL_GET_FREE that returns unused device, so you don't have to
> scan all the /dev/loopN devices to detect a free device.
Thanks for the info!
>
> > 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.
>
> Again, I don't think it's so important for zram as for loop devices.
> All depends how people will use zram devices. We will see...
Yeb and we can do it when we see.
>
> Karel
>
> --
> Karel Zak <kzak@redhat.com>
> http://karelzak.blogspot.com
next prev parent reply other threads:[~2014-08-05 8:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 23:14 zram: device management utility needed Sami Kerola
2014-08-04 12:39 ` Sergey Senozhatsky
2014-08-05 2:00 ` Minchan Kim
2014-08-05 7:07 ` Karel Zak
2014-08-05 8:12 ` Minchan Kim [this message]
2014-08-05 8:26 ` Sami Kerola
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=20140805081238.GA3700@gmail.com \
--to=minchan@kernel.org \
--cc=kerolasa@iki.fi \
--cc=kzak@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nefelim4ag@gmail.com \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=util-linux@vger.kernel.org \
/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.