mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: clameter@engr.sgi.com, linux-kernel@vger.kernel.org,
	manfred@colorfullife.com, shai@scalex86.org,
	alok.kataria@calsoftinc.com, sonny@burdell.org,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [patch 2/3] NUMA slab locking fixes - move irq disabling from cahep->spinlock to l3 lock
Date: Mon, 6 Feb 2006 15:30:08 -0800	[thread overview]
Message-ID: <20060206153008.361202e1.akpm@osdl.org> (raw)
In-Reply-To: <20060206225117.GB3578@localhost.localdomain>

Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
> On Sat, Feb 04, 2006 at 01:48:28AM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> > >
> > > Earlier, we had to disable on chip interrupts while taking the cachep->spinlock
> > >  because, at cache_grow, on every addition of a slab to a slab cache, we 
> > >  incremented colour_next which was protected by the cachep->spinlock, and
> > >  cache_grow could occur at interrupt context.  Since, now we protect the 
> > >  per-node colour_next with the node's list_lock, we do not need to disable 
> > >  on chip interrupts while taking the per-cache spinlock, but we
> > >  just need to disable interrupts when taking the per-node kmem_list3 list_lock.
> > 
> > It'd be nice to have some comments describing what cachep->spinlock
> > actually protects.
> 
> Actually, it does not protect much anymore.  Here's a cleanup+comments
> patch (against current mainline).

This is getting scary.  Manfred, Christoph, Pekka: have you guys taken a
close look at what's going on in here?

> The non atomic stats on the cachep structure now needs serialization though,
> would a spinlock be better there instead of changing them over to atomic_t s
> ? I wonder...

It's common for the kernel to use non-atomic ops for stats such as this
(networking especially).  We accept the small potential for small
inaccuracy as an acceptable tradeoff for improved performance.

But given that a) these stats are only enabled with CONFIG_DEBUG_SLAB and
b) CONFIG_DEBUG_SLAB causes performance to suck the big one anyway and c)
the slab.c stats are wrapped in handy macros, yes, I guess it wouldn't hurt
to make these guys atomic_t.  Sometime.  My slab.c is looking rather
overpatched again at present.

A problem right now is the -mm-only slab debug patches
(slab-leak-detector.patch, slab-cache-shrinker-statistics.patch and the
currently-dropped
periodically-scan-redzone-entries-and-slab-control-structures.patch).  It
would be good if we could finish these things off and get them into mainline
so things get a bit sane again.



  reply	other threads:[~2006-02-06 23:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 20:53 [patch 0/3] NUMA slab locking fixes Ravikiran G Thirumalai
2006-02-03 20:55 ` [patch 1/3] NUMA slab locking fixes -- slab-colour-next fix Ravikiran G Thirumalai
2006-02-03 20:56 ` [patch 2/3] NUMA slab locking fixes -- slab locking irq optimizations Ravikiran G Thirumalai
2006-02-03 20:57 ` [patch 3/3] NUMA slab locking fixes -- slab cpu hotplug fix Ravikiran G Thirumalai
2006-02-03 22:07 ` [patch 0/3] NUMA slab locking fixes Andrew Morton
2006-02-03 23:06   ` Christoph Lameter
2006-02-04  1:08     ` Ravikiran G Thirumalai
2006-02-04  1:15       ` [patch 1/3] NUMA slab locking fixes -- move color_next to l3 Ravikiran G Thirumalai
2006-02-04  1:22       ` [patch 0/3] NUMA slab locking fixes Andrew Morton
2006-02-04  1:28       ` [patch 2/3] NUMA slab locking fixes - move irq disabling from cahep->spinlock to l3 lock Ravikiran G Thirumalai
2006-02-04  9:48         ` Andrew Morton
2006-02-06 22:51           ` Ravikiran G Thirumalai
2006-02-06 23:30             ` Andrew Morton [this message]
2006-02-07  0:21               ` Christoph Lameter
2006-02-07  7:36                 ` Pekka J Enberg
2006-02-07  7:50                   ` Ravikiran G Thirumalai
2006-02-07  7:55                     ` Pekka J Enberg
2006-02-04  1:29       ` [patch 3/3] NUMA slab locking fixes -- fix cpu down and up locking Ravikiran G Thirumalai
2006-02-04 10:03         ` Andrew Morton
2006-02-04 10:05           ` Andrew Morton

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=20060206153008.361202e1.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=alok.kataria@calsoftinc.com \
    --cc=clameter@engr.sgi.com \
    --cc=kiran@scalex86.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=shai@scalex86.org \
    --cc=sonny@burdell.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

Powered by JetHome