public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: David Howells <dhowells@redhat.com>
Cc: Fabian Frederick <fabf@skynet.be>,
	linux-kernel@vger.kernel.org, akpm <akpm@linux-foundation.org>,
	cl@linux-foundation.org
Subject: Re: Has slab ctor operation changed? -- was [PATCH 1/1] afs: afs_alloc_inode: use kmem_cache_zalloc
Date: Fri, 21 Feb 2014 11:19:46 +1100	[thread overview]
Message-ID: <20140221001946.GV4916@dastard> (raw)
In-Reply-To: <32740.1392934995@warthog.procyon.org.uk>

On Thu, Feb 20, 2014 at 10:23:15PM +0000, David Howells wrote:
> Fabian Frederick <fabf@skynet.be> wrote:
> 
> > afs_vnode is currently cleared with 2 memsets after allocation and 
> > 1 in constructor (afs_i_init_once).
> > 	-This patch calls zalloc for explicit zero fill.
> 
> Ummm...  This patch isn't necessarily correct in the substantiative portions.
> 
> Since afs_i_init_once() is called by the slab allocator during the course of
> kmem_cache_alloc(), how does kmem_cache_zalloc() interact with that?

It breaks it. ;)

> IIRC, it used to be that the ctor() function was called when the pages were
> allocated to the slab - and it wasn't called again, even if the object was
> allocated, deallocated and reallocated.  This means that things like locks and
> lists don't need reinitialising after allocation.
> 
> So afs_i_init_once() theoretically constructs the stuff that can be reused,
> and afs_alloc_inode() therefore has to clear the non-reusable state.
> 
> Of course, it's possible that the slab allocator no longer works like this...

AFAIA the slab constructor behaviour has not changed. If it did, I'm
pretty sure most filesystems would end up with inode cache problems
because most of them rely on this ctor behaviour to avoid
unnecessary reinitialisation of inode state....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2014-02-21  0:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20 13:16 [PATCH 1/1] afs: afs_alloc_inode: use kmem_cache_zalloc Fabian Frederick
2014-02-20 21:30 ` Joe Perches
2014-02-20 22:03   ` David Howells
2014-02-20 22:23 ` Has slab ctor operation changed? -- was " David Howells
2014-02-20 21:47   ` Fabian Frederick
2014-02-21  0:19   ` Dave Chinner [this message]
2014-02-24 19:52   ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140221001946.GV4916@dastard \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=fabf@skynet.be \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox