Hi Linus,
I managed to miss the merge window. Sorry about that!
Please consider pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/for-linus
It contains more of Christoph's SLAB unification work that reduce the
differences between different slab allocators. The code has been sitting
in linux-next without problems.
If you feel this is inappropriate for -rc2, just skip the pull and I'll
requeue it for 3.10.
Pekka
------------------>
The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/for-linus
Christoph Lameter (15):
slab: Use proper formatting specs for unsigned size_t
slab: Move kmalloc related function defs
slab: Common kmalloc slab index determination
slab: Use common kmalloc_index/kmalloc_size functions
slab: Common name for the per node structures
slab: Rename nodelists to node
slab: Common constants for kmalloc boundaries
slab: Common definition for the array of kmalloc caches
slab: Common function to create the kmalloc array
stat: Use size_t for sizes instead of unsigned
slab: Common Kmalloc cache determination
slab: Rename list3/l3 to node
slab: Common definition for kmem_cache_node
slab: Handle ARCH_DMA_MINALIGN correctly
slab: Fixup CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections
Glauber Costa (1):
slub: correctly bootstrap boot caches
Joonsoo Kim (1):
mm/sl[au]b: correct allocation type check in kmalloc_slab()
Pekka Enberg (1):
Merge branch 'slab/next' into slab/for-linus
fs/proc/stat.c | 2 +-
include/linux/kmalloc_sizes.h | 45 ---
include/linux/slab.h | 231 +++++++++----
include/linux/slab_def.h | 48 +--
include/linux/slub_def.h | 136 +-------
mm/slab.c | 789 +++++++++++++++++------------------------
mm/slab.h | 43 +++-
mm/slab_common.c | 165 +++++++++-
mm/slub.c | 188 +---------
9 files changed, 745 insertions(+), 902 deletions(-)
delete mode 100644 include/linux/kmalloc_sizes.h
On Mon, Mar 4, 2013 at 2:35 AM, Pekka Enberg <[email protected]> wrote:
>
> It contains more of Christoph's SLAB unification work that reduce the
> differences between different slab allocators. The code has been sitting
> in linux-next without problems.
>
> If you feel this is inappropriate for -rc2, just skip the pull and I'll
> requeue it for 3.10.
Ugh. It only came a day late, and if you had pushed a bit harder, I'd
have pulled it. But when you put it that way, I really cannot see any
valid reason why it cannot wait, and so I think I'll just expect it
for the next release.
If you change your mind and realize that it fixes some major bug and
really needs to be pulled after all, holler.
Linus
On Tue, 5 Mar 2013, Linus Torvalds wrote:
> On Mon, Mar 4, 2013 at 2:35 AM, Pekka Enberg <[email protected]> wrote:
> >
> > It contains more of Christoph's SLAB unification work that reduce the
> > differences between different slab allocators. The code has been sitting
> > in linux-next without problems.
> >
> > If you feel this is inappropriate for -rc2, just skip the pull and I'll
> > requeue it for 3.10.
>
> Ugh. It only came a day late, and if you had pushed a bit harder, I'd
> have pulled it. But when you put it that way, I really cannot see any
> valid reason why it cannot wait, and so I think I'll just expect it
> for the next release.
>
> If you change your mind and realize that it fixes some major bug and
> really needs to be pulled after all, holler.
Well this stuff was already ready for 3.8 and missed that merge period as
well. There are a couple of bug fixes included as well. It is the basis
for more common code between allocators. Most of it is renaming things so
that fields have a common name which enables more code sharing.
Hi Christoph,
On Wed, Mar 6, 2013 at 6:38 PM, Christoph Lameter <[email protected]> wrote:
> Well this stuff was already ready for 3.8 and missed that merge period as
> well. There are a couple of bug fixes included as well. It is the basis
> for more common code between allocators. Most of it is renaming things so
> that fields have a common name which enables more code sharing.
It was me who missed the merge window - sorry about that. But is there
really any real need to push this through at such late stage? People
will work on "slab/next" branch anyway so what's the rush?
We had quite a lot of changes due to slab memcg and I'd rather keep
things calm for this release cycle. It usually takes a few cycles for
people to start noticing problems and it doesn't really help if
there's code churn going on all the time.
Pekka