All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Elsayed <eternaleye@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 RESEND] zram: auto add new devices on demand
Date: Fri, 08 Aug 2014 02:13:44 -0700	[thread overview]
Message-ID: <ls24ca$u8q$1@ger.gmane.org> (raw)
In-Reply-To: 20140805014917.GA27993@bbox

Minchan Kim wrote:

> On Wed, Jul 30, 2014 at 10:58:31PM +0900, Sergey Senozhatsky wrote:
>> Hello,
>> 
>> On (07/29/14 12:00), Minchan Kim wrote:
>> > Hello Timofey,
>> > 

<snip>

>> > Why do you add new device unconditionally?
>> > Maybe we need new konb on sysfs or ioctl for adding new device?
>> > Any thought, guys?
>> 
>> 
>> speaking of the patch, frankly, I (almost) see no gain comparing to the
>> existing functionality.
>> 
>> speaking of the idea. well, I'm not 100% convinced yet. the use cases I
>> see around do not imply dynamic creation/resizing/etc. that said, I need
>> to think about it.
> 
> It didn't persuade me, either.
> 
> Normally, distro have some config file for adding param at module loading
> like /etc/modules. So, I think it should be done in there if someone want
> to increase the number of zram devices.

The problem here is that this requires (at least) unloading the module, and 
if it was built in requires a reboot (and futzing with the kernel command 
line, rather than /etc/modules.d)

If someone's distro already loaded the module with nr_devices=1 (the 
default, I remind you), and is using it as swap, then it may well not be a 
feasible option for them to swapoff the (potentially large) swap device and 
do the modprobe dance.

If they're running off a livecd that's using it in combination with, say, 
LVM thin provisioning in order to have a writeable system, then they are 
_completely_ screwed because you can't swapoff your rootfs.

If they're using it as a backing store for ephemeral containers or VMs, then 
they may hit _any_ static limit, when they just want to start one more 
without having to stop the existing bunch.

The swap case might be argued as "deal with it" (despite that swapoff is not 
something fun to do on a system under any real-world load, _especially_ if 
what you're trying to force off of the swap device won't fit in ram and has 
to get pushed down to a different swap device).

But any case where people put filesystems on the device should make the 
issues of only supporting the module parameter pretty apparent.

Finally, there's the issue of clutter - I may need 4 zram devices when I'm 
experimenting with something, but only the one swap device for daily use. 
Having the other three just sitting around permanently is at most an 
annoyance, a 'papercut' - but papercuts add up.

>> 
>> if we end up adding this functionality I tend to vote for sysfs knob,
>> just because it seems to be more user friendly than writing some magic
>> INTs to ioctl-d fd.

This I agree with wholeheartedly.

<snip>



      reply	other threads:[~2014-08-08  9:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 10:46 [PATCH v3 RESEND] zram: auto add new devices on demand Timofey Titovets
2014-07-29  3:00 ` Minchan Kim
2014-07-29 21:12   ` Timofey Titovets
2014-07-30 13:58   ` Sergey Senozhatsky
2014-08-05  1:49     ` Minchan Kim
2014-08-08  9:13       ` Alex Elsayed [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='ls24ca$u8q$1@ger.gmane.org' \
    --to=eternaleye@gmail.com \
    --cc=linux-kernel@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.