On Wed, 7 Mar 2007, Matt Mackall wrote:
> > I have a patch here to make this dependent on page size using a loop. The
> > problem is that it does not work with some versions of gcc. On the
> > other hand we really need this since one arch can
> > actually have an order 22 page size!
>
> You do
On Wed, Mar 07, 2007 at 07:34:38AM -0800, Christoph Lameter wrote:
> On Wed, 7 Mar 2007, Peter Zijlstra wrote:
>
> > > return -1;
> > > }
> >
> > Perhaps so something with PAGE_SIZE here, as you know there are
> > platforms/configs where PAGE_SIZE != 4k :-)
>
> Any allocation > 2k just uses a
On Wed, 7 Mar 2007, Peter Zijlstra wrote:
> > return -1;
> > }
>
> Perhaps so something with PAGE_SIZE here, as you know there are
> platforms/configs where PAGE_SIZE != 4k :-)
Any allocation > 2k just uses a regular allocation which will waste space.
I have a patch here to make this depen
On Tue, 2007-03-06 at 18:35 -0800, Christoph Lameter wrote:
> Unlimited kmalloc size and removal of general caches >=4.
>
> We can directly use the page allocator for all allocations 4K and larger. This
> means that no general slabs are necessary and the size of the allocation
> passed
> to kmall
On Tue, 6 Mar 2007, Matt Mackall wrote:
> I've been meaning to do this in SLOB as well. Perhaps it warrants
> doing in stock kmalloc? I've got a grand total of 18 of these objects
> here.
The number increases with the number numa nodes. We have had trouble with
the maximum kmalloc size before and
On Tue, Mar 06, 2007 at 06:35:16PM -0800, Christoph Lameter wrote:
> Unlimited kmalloc size and removal of general caches >=4.
>
> We can directly use the page allocator for all allocations 4K and larger. This
> means that no general slabs are necessary and the size of the allocation
> passed
> t
6 matches
Mail list logo
