Re: max_loop limit

From: Jens Axboe
Date: Thu Mar 22 2007 - 09:46:30 EST


On Thu, Mar 22 2007, Eric Dumazet wrote:
> On Thu, 22 Mar 2007 12:37:54 +0100
> Tomas M <tomas@xxxxxxxx> 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 :)

But this still wastes memory, why not just allocate each loop device
dynamically when it is set up? The current approach is crap, it is just
wasting memory for loop devices, queues, etc.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/