Re: Fw: two 2.6.13-rc3-mm3 oddities

[Andrew Morton <akpm@osdl.org>]

Dipankar Sarma <dipankar@in.ibm.com> wrote:
>
> On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote:
> > Dipankar Sarma wrote:
> > 
> > >Hugh, could you please try this with the experimental patch below ?
> > >Manfred, is it safe to decrement nr_files in file_free()
> > >instead of the destructor ? I can't see any problem.
> > >
> > > 
> > >
> > The ctor/dtor are only called when new objects are created, not on every 
> > kmem_cache_alloc/kmem_cache_free. Thus I would expect that the counter 
> > becomes negative on builds without CONFIG_DEBUG_SLAB.
> > Thus increase in the ctor and decrease in file_free() is the wrong 
> > thing. If you want to move the decrease from the dtor to file_free, then 
> > you must move the increase, too.
> > But: IIRC the counters were moved to the ctor/dtor for performance 
> > reasons, I'd guess mbligh ran into cache line trashing on the 
> > filp_count_lock spinlock with reaim or something like that.
> 
> Ah, so the whole idea was to inc/dec nr_files less often so
> that we reduce contention on filp_count_lock, right ? This however
> causes skews nr_files by the size of the slab array, AFAICS.
> Since we check nr_files before we allocate files from slab, the
> check seems inaccurate.
> 
> Anyway, I guess, I need to look at scaling the file counting
> first.

Something like vm_acct_memory() or percpu_counter would suit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/