[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070322144210.73dfaf83.dada1@cosmosbay.com>
Date: Thu, 22 Mar 2007 14:42:10 +0100
From: Eric Dumazet <dada1@...mosbay.com>
To: Tomas M <tomas@...x.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: max_loop limit
On Thu, 22 Mar 2007 12:37:54 +0100
Tomas M <tomas@...x.org> wrote:
> The question is not "Why do we need more than 255 loops?".
> The question should be "Why do we need the hardcoded 255-limit in kernel
> while there is no reason for it at all?"
>
> My patch simply removes the hardcoded limitation.
Hello Tomas, welcome !
Well, its an attempt to remove a hardcoded limit, but as you said in the Changelog, it really depends on kmalloc() being able to allocate a large continous memory zone. Alas it might fail.
The golden rule is to avoid all allocations larger than PAGE_SIZE :)
On x86_64, sizeof(struct loop_device) is 368, so the 'new limit' would be 356 instead of 256...
You might want a more radical patch :
Instead of using :
static struct loop_device *loop_dev;
loop_dev = kmalloc(max_loop * sizeof(struct loop_device));
Switch to :
static struct loop_device **loop_dev;
loop_dev = kmalloc(max_loop * sizeof(void *));
if (!loop_dev) rollback...
for (i = 0 ; i < max_loop ; i++) {
loop_dev[i] = kmalloc(sizeof(struct loop_device));
if (!loop_dev[i]) rollback...
}
This time, you would be limited to 16384 loop devices on x86_64, 32768 on i386 :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists