On Fri, 4 May 2007, Christoph Lameter wrote:
> Also could this be generalized to also apply to the generic inode
> allocation in fs/inode.c?
I think we want to stick inode_init_ince() in alloc_inode() but we can't
do that until all filesystems are converted over.
Pekka
-
On Sat, 5 May 2007, Andrew Morton wrote:
> I doubt if this is measurable, really. It'll be something like the
> difference between an L1 hit and an L2 hit in amongst all the other stuff
> we do on a per-inode basis.
The cache effects are probably not easily measurable but I was worried
about CPU
On Sat, 5 May 2007 11:58:45 +0300 (EEST) Pekka J Enberg <[EMAIL PROTECTED]>
wrote:
> On Fri, 4 May 2007, Andrew Morton wrote:
> > I got 100% rejects against this because Christoph has already had
> > his paws all over the slab constructor code everywhere.
> >
> > Was going to fix it up but then
On Fri, 4 May 2007, Andrew Morton wrote:
> I got 100% rejects against this because Christoph has already had
> his paws all over the slab constructor code everywhere.
>
> Was going to fix it up but then decided that we ought to make changes
> like this to ext4 as well. Ideally beforehand, but sim
On Fri, 4 May 2007 13:14:35 +0300 (EEST)
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> As explained by Christoph Lameter, ext3_alloc_inode() touches the same
> cache line as init_once() so we gain nothing from using slab
> constructors. The SLUB allocator will be more effective without it
> (free p
On Fri, 4 May 2007, Pekka J Enberg wrote:
> Index: 2.6/fs/ext3/super.c
> ===
> --- 2.6.orig/fs/ext3/super.c 2007-05-04 12:57:09.0 +0300
> +++ 2.6/fs/ext3/super.c 2007-05-04 13:01:27.0 +0300
> @@ -444,17 +444,26
From: Pekka Enberg <[EMAIL PROTECTED]>
As explained by Christoph Lameter, ext3_alloc_inode() touches the same
cache line as init_once() so we gain nothing from using slab
constructors. The SLUB allocator will be more effective without it
(free pointer can be placed inside the free'd object), so m
7 matches
Mail list logo
