LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tomas M <tomas@slax.org>
To: linux-kernel@vger.kernel.org
Subject: max_loop limit
Date: Thu, 22 Mar 2007 08:57:02 +0100	[thread overview]
Message-ID: <460236CE.1030303@slax.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

Hello,

this is my first code submitted to kernel, I hope you won't hate it.

This 4-lines-change patch adds support for nearly two-times more loop
devices. Explanation follows:

The maximum amount of loop devices has been 255 for many years, while
there is a lot of space for more. The maximum depends on max memory
available from kmalloc(), which is usually 128KB, but can be increased
in some cases.

It would be better to support thousands of loop devices of course, but
the change could be more complicated (perhaps replace kmalloc by
vmalloc). This four lines change is just simple and sufficient, without
any need for kmalloc replacement.

I only removed the test if (max_loop > 255), so now we support much more
loop devices then before, without ANY OTHER CHANGE to the code.

Information: The maximum max_loop is 455 if kmalloc can allocate 128KB,
so the amount is nearly doubled without any significant change to kernel
code. The maximum could be even bigger I guess, it probably depends on:
NR_CPUS, MAX_NUMNODES, CONFIG_MMU and CONFIG_LARGE_ALLOCS.

If kmalloc can't allocate enough RAM, loop is simply unloaded.


Thank you for your consideration.

I hope you will like it and you will include it in kernel.
Or, if not, maybe this patch will start some debate regarding
the current insufficient limit of 255 loop devices.


Tomas M
slax.org



[-- Attachment #2: loop.c.diff --]
[-- Type: text/x-patch, Size: 1861 bytes --]

--- linux/drivers/block/loop_old.c	2007-02-04 18:44:54.000000000 +0000
+++ linux/drivers/block/loop.c	2007-03-22 08:31:55.000000000 +0000
@@ -44,6 +44,16 @@
  * backing filesystem.
  * Anton Altaparmakov, 16 Feb 2005
  *
+ * The maximum amount of loop devices has been 255 for many years, while there
+ * is a lot of space for more. The maximum depends on max memory available 
+ * from kmalloc, which is usually 128KB, but can be even more.
+ * I removed the test if (max_loop > 255), so now we support much more loop 
+ * devices then before; it probably depends on:
+ *    NR_CPUS, MAX_NUMNODES, CONFIG_MMU and CONFIG_LARGE_ALLOCS.
+ * Information: The maximum max_loop is 455 if kmalloc handles only 128KB.
+ * If kmalloc can't allocate enough RAM, loop is simply unloaded.
+ * Author: Tomas Matejicek, www.slax.org, 21 Mar 2007
+ *
  * Still To Fix:
  * - Advisory locking is ignored here.
  * - Should use an own CAP_* category instead of CAP_SYS_ADMIN
@@ -1358,7 +1368,7 @@
  * And now the modules code and kernel interface.
  */
 module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
+MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-455 on i386)");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
 
@@ -1402,9 +1412,9 @@
 {
 	int	i;
 
-	if (max_loop < 1 || max_loop > 256) {
-		printk(KERN_WARNING "loop: invalid max_loop (must be between"
-				    " 1 and 256), using default (8)\n");
+	if (max_loop < 1) {
+		printk(KERN_WARNING "loop: invalid max_loop (must be at least 1"
+				    ", using default (8)\n");
 		max_loop = 8;
 	}
 
@@ -1465,7 +1475,7 @@
 	kfree(loop_dev);
 out_mem1:
 	unregister_blkdev(LOOP_MAJOR, "loop");
-	printk(KERN_ERR "loop: ran out of memory\n");
+	printk(KERN_ERR "loop: ran out of memory for max_loop=%d\n", max_loop);
 	return -ENOMEM;
 }
 

             reply	other threads:[~2007-03-22  8:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-22  7:57 Tomas M [this message]
2007-03-22 11:00 ` markus reichelt
2007-03-22 11:37   ` Tomas M
2007-03-22 13:42     ` Eric Dumazet
2007-03-22 13:42       ` Jens Axboe
2007-03-22 13:52         ` Eric Dumazet
2007-03-22 13:54           ` Jens Axboe
2007-03-22 14:11             ` William Lee Irwin III
2007-03-22 15:22               ` Arjan van de Ven
2007-03-22 16:09               ` Pádraig Brady
2007-03-28 23:34                 ` Karel Zak
     [not found]             ` <20070322151826.c1421851.dada1@cosmosbay.com>
     [not found]               ` <20070322142306.GU19922@kernel.dk>
     [not found]                 ` <20070322153603.1f5d442d.dada1@cosmosbay.com>
2007-03-22 15:31                   ` max_loop limit - paid job offer Tomas M
2007-03-22 14:33         ` max_loop limit Al Viro
2007-03-22 19:51           ` Olivier Galibert
2007-03-22 14:25       ` Tomas M
2007-03-23  1:34       ` Jan Engelhardt
2007-03-23 23:26         ` [PATCH] " Jan Engelhardt
2007-03-25  0:17           ` Ken Chen
2007-03-25  0:29           ` Ken Chen
2007-03-25  8:40           ` Tomas M
2007-03-28 23:41             ` Karel Zak
2007-03-29  3:54           ` Kyle Moffett
2007-03-29  4:16             ` [PATCH] max_loop limit, t2 Jan Engelhardt
2007-03-29  8:38               ` [PATCH] max_loop limit, loop.c final working version Tomas M
2007-03-29 14:16     ` max_loop limit Bill Davidsen
2007-03-22 13:53 devzero
2007-03-22 23:23 devzero
2007-03-23  8:59 ` Tomas M
2007-03-22 23:37 roland
2007-03-29 14:20 ` Bill Davidsen

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=460236CE.1030303@slax.org \
    --to=tomas@slax.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: max_loop limit' \
    /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

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).