[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1316726425.31040.35.camel@twins>
Date: Thu, 22 Sep 2011 23:20:25 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Joe Perches <joe@...ches.com>
Cc: Colin Cross <ccross@...roid.com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH 3/3] seq_file: convert seq buffer to vmalloc
On Thu, 2011-09-22 at 14:07 -0700, Joe Perches wrote:
> On Thu, 2011-09-22 at 13:57 -0700, Colin Cross wrote:
> > seq_files are often used for debugging. When things are going wrong
> > due to failed physically contiguous allocations, the exponentially
> > growing physically contiguous allocations in seq_read can make things
> > worse. There is no need for physically contiguous memory, so switch
> > to virtually contiguous memory instead.
>
> vmalloc's are relatively expensive.
And very limited on certain archs..
> Perhaps use kmalloc when appropriate instead?
>
> []
> > - /* don't ask for more than the kmalloc() max size */
> > - if (size > KMALLOC_MAX_SIZE)
> > - size = KMALLOC_MAX_SIZE;
> > -
> > - buf = kmalloc(size, GFP_KERNEL);
> > + buf = vmalloc(size);
> > if (!buf)
> > return -ENOMEM;
>
> if (size > KMALLOC_MAX_SIZE)
> buf = vmalloc(size, GFP_KERNEL)
> else
> buf = kmalloc(size, GFP_KERNEL)
There's wrappers for this stuff IIRC, that said all this is a horrible
idea. Just avoid the situation instead of coping with it.
--
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