[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1511040748590.17248@east.gentwo.org>
Date: Wed, 4 Nov 2015 07:53:50 -0600 (CST)
From: Christoph Lameter <cl@...ux.com>
To: Catalin Marinas <catalin.marinas@....com>
cc: Robert Richter <rric@...nel.org>, Joonsoo Kim <js1304@...il.com>,
Linux-sh list <linux-sh@...r.kernel.org>,
Will Deacon <will.deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Robert Richter <rrichter@...ium.com>,
Tirumalesh Chalamarla <tchalamarla@...ium.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, linux-mm@...ck.org
Subject: Re: [PATCH] arm64: Increase the max granular size
On Wed, 4 Nov 2015, Catalin Marinas wrote:
> The simplest option would be to make sure that off slab isn't allowed
> for caches of KMALLOC_MIN_SIZE or smaller, with the drawback that not
> only "kmalloc-128" but any other such caches will be on slab.
The reason for an off slab configuration is denser object packing.
> I think a better option would be to first check that there is a
> kmalloc_caches[] entry for freelist_size before deciding to go off-slab.
Hmmm.. Yes seems to be an option.
Maybe we simply revert commit 8fc9cf420b36 instead? That does not seem to
make too much sense to me and the goal of the commit cannot be
accomplished on ARM. Your patch essentially reverts the effect anyways.
Smaller slabs really do not need off slab management anyways since they
will only loose a few objects per slab page.
--
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