From: Alok Kataria <alokk@calsoftinc.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Christoph Lameter <clameter@engr.sgi.com>,
vandrove@vc.cvut.cz, linux-kernel@vger.kernel.org,
manfred@colorfullife.com,
Ravikiran G Thirumalai <kiran@scalex86.org>
Subject: Re: 2.6.14-rc1-git-now still dying in mm/slab - this time line 1849
Date: Tue, 20 Sep 2005 14:04:20 +0530 [thread overview]
Message-ID: <1127205260.3536.23.camel@alok.intranet.calsoftinc.com> (raw)
In-Reply-To: <20050919221614.6c01c2d1.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]
Hi,
Attached is a patch which stores the numa_node_id in a local variable
after disabling interrupts, in the cache_reap code path.
I was not able to reproduce the bug that Petr was talking about, but if
the cache reap threads do schedule across cpu's which might be the
problem here then this should just fix it.
Andrew, i also have a patch which fixes the CPU_DOWN code path, which i
will send u later.
Thanks & Regards,
Alok.
On Tue, 2005-09-20 at 10:46, Andrew Morton wrote:
> Christoph Lameter <clameter@engr.sgi.com> wrote:
> >
> > On Mon, 19 Sep 2005, Andrew Morton wrote:
> >
> > > list_for_each(walk, &cache_chain) {
> > > kmem_cache_t *searchp;
> > > struct list_head* p;
> > > int tofree;
> > > struct slab *slabp;
> > >
> > > searchp = list_entry(walk, kmem_cache_t, next);
> > >
> > > if (searchp->flags & SLAB_NO_REAP)
> > > goto next;
> > >
> > > check_irq_on();
> > >
> > > l3 = searchp->nodelists[numa_node_id()];
> > > if (l3->alien)
> > > drain_alien_cache(searchp, l3);
> > > ->preempt here
> > > spin_lock_irq(&l3->list_lock);
> > >
> > > drain_array_locked(searchp, ac_data(searchp), 0,
> > > numa_node_id());
> > > ->oops, wrong node.
> >
> > This is called from keventd which exists per processor. Hmmm... This looks
> > as if it can change processors after all
>
> Well no, it would be a big bug if a keventd thread were to change CPUs.
>
> It's OK to rely upon the pinnedness of keventd I guess - a comment would be
> nice.
>
> > but the slab allocator depends on
> > it running on the right processor. So does the page allocator. sigh. What
> > is the point of having per processor workqueues if they do not stay on
> > the assigned processor?
>
> They do. I don't believe that preemption is the source of this BUG.
> (Petr, does CONFIG_PREEMPT=n fix it?)
>
> > The fast fix for this case is to get the node number once and then use it
> > consistently.
>
> If one is writing preempt-safe code then one should disable preemption
> before copying the current CPU number into a local variable.
>
> > But we really need to audit the slab and page allocator for
> > additional cases like this or disable preempt and check for the right
> > processor in cache_reap().
>
> numa_node_id() must use smp_processor_id(), not raw_smp_processor_id().
> Then all the runtime squawks need to be audited and fixed, or switched to
> (new) raw_numa_node_id() if is is verified that a CPU/node switch at any
> time is OK.
>
--
There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies. And the other way
is to make it so complicated that there are no obvious deficiencies.
[-- Attachment #2: cache_reap_nodeid.patch --]
[-- Type: text/x-patch, Size: 1442 bytes --]
Signed-off-by: Alok N Kataria <alokk@calsoftinc.com>
Index: linux-2.6.13/mm/slab.c
===================================================================
--- linux-2.6.13.orig/mm/slab.c 2005-09-13 20:56:33.040284000 +0530
+++ linux-2.6.13/mm/slab.c 2005-09-20 13:22:08.328464250 +0530
@@ -3273,7 +3273,7 @@
list_for_each(walk, &cache_chain) {
kmem_cache_t *searchp;
struct list_head* p;
- int tofree;
+ int tofree, nodeid;
struct slab *slabp;
searchp = list_entry(walk, kmem_cache_t, next);
@@ -3283,13 +3283,19 @@
check_irq_on();
- l3 = searchp->nodelists[numa_node_id()];
+ nodeid = numa_node_id();
+ l3 = searchp->nodelists[nodeid];
if (l3->alien)
drain_alien_cache(searchp, l3);
- spin_lock_irq(&l3->list_lock);
+
+ local_irq_disable();
+ nodeid = numa_node_id();
+ l3 = searchp->nodelists[nodeid];
+
+ spin_lock(&l3->list_lock);
drain_array_locked(searchp, ac_data(searchp), 0,
- numa_node_id());
+ nodeid);
if (time_after(l3->next_reap, jiffies))
goto next_unlock;
@@ -3298,7 +3304,7 @@
if (l3->shared)
drain_array_locked(searchp, l3->shared, 0,
- numa_node_id());
+ nodeid);
if (l3->free_touched) {
l3->free_touched = 0;
@@ -3327,7 +3333,8 @@
spin_lock_irq(&l3->list_lock);
} while(--tofree > 0);
next_unlock:
- spin_unlock_irq(&l3->list_lock);
+ spin_unlock(&l3->list_lock);
+ local_irq_enable();
next:
cond_resched();
}
next prev parent reply other threads:[~2005-09-20 8:32 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-15 16:51 Petr Vandrovec
2005-09-15 17:33 ` Petr Vandrovec
[not found] ` <20050916023005.4146e499.akpm@osdl.org>
[not found] ` <432AA00D.4030706@vc.cvut.cz>
[not found] ` <20050916230809.789d6b0b.akpm@osdl.org>
2005-09-19 16:02 ` Petr Vandrovec
2005-09-19 18:29 ` Andrew Morton
2005-09-19 18:51 ` Christoph Lameter
2005-09-19 19:28 ` Andrew Morton
2005-09-19 21:20 ` Christoph Lameter
2005-09-20 5:16 ` Andrew Morton
2005-09-20 8:34 ` Alok Kataria [this message]
2005-09-20 13:58 ` Petr Vandrovec
2005-09-21 1:03 ` Christoph Lameter
2005-09-21 1:22 ` Petr Vandrovec
2005-09-21 15:59 ` Christoph Lameter
2005-09-22 19:52 ` Christoph Lameter
2005-09-22 20:01 ` Andrew Morton
2005-09-22 21:25 ` Petr Vandrovec
2005-09-22 21:32 ` Christoph Lameter
2005-09-22 21:46 ` Andrew Morton
2005-09-22 21:54 ` Christoph Lameter
2005-09-23 0:25 ` Petr Vandrovec
2005-09-28 21:02 ` Ravikiran G Thirumalai
2005-09-28 22:50 ` Christoph Lameter
2005-09-29 16:43 ` Petr Vandrovec
2005-09-29 18:11 ` Ravikiran G Thirumalai
2005-09-29 18:38 ` Christoph Lameter
2005-09-30 5:45 ` Ravikiran G Thirumalai
2005-09-30 6:05 ` Andrew Morton
2005-09-30 6:28 ` Ravikiran G Thirumalai
2005-09-30 15:16 ` Bryan O'Sullivan
2005-09-30 15:57 ` Christoph Lameter
2005-09-30 16:45 ` Bryan O'Sullivan
2005-09-30 20:11 ` Andi Kleen
2005-09-30 20:23 ` Ravikiran G Thirumalai
2005-09-30 16:55 ` Christoph Lameter
2005-09-19 18:56 ` Petr Vandrovec
2005-09-19 19:08 ` Christoph Lameter
2005-09-23 19:34 Alok Kataria
2005-09-23 23:57 ` Christoph Lameter
2005-09-24 0:05 ` Christoph Lameter
2005-09-24 12:52 ` Manfred Spraul
2005-09-25 14:16 Alok Kataria
2005-09-26 18:00 ` Christoph Lameter
2005-09-26 19:34 ` Alok Kataria
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=1127205260.3536.23.camel@alok.intranet.calsoftinc.com \
--to=alokk@calsoftinc.com \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=kiran@scalex86.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=vandrove@vc.cvut.cz \
/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
all inboxes | Powered by JetHome®