lkml.org 
[lkml]   [2014]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Has slab ctor operation changed? -- was [PATCH 1/1] afs: afs_alloc_inode: use kmem_cache_zalloc
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


\
 
 \ /
  Last update: 2014-02-21 02:01    [W:0.605 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site