From: Alex Chiang <achiang@hp.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: tony.luck@intel.com, linux-ia64@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RCU can use cpu_active_map?
Date: Mon, 09 Feb 2009 22:50:00 +0000 [thread overview]
Message-ID: <20090209225000.GC3939@ldl.fc.hp.com> (raw)
In-Reply-To: <20090209213929.GQ6802@linux.vnet.ibm.com>
* Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> On Mon, Feb 09, 2009 at 01:13:45PM -0700, Alex Chiang wrote:
> > Paul,
> >
> > I don't pretend to understand RCU, but a very quick and naive
> > look through rcupreempt.c makes me think that we could use the
> > cpu_active_map instead of cpu_online_map?
> >
> > cpu_active_map was introduced by e761b772.
> >
> > In the CPU hotplug path, we touch the cpu_active_map very early
> > on:
> >
> > int __ref cpu_down(unsigned int cpu)
> > {
> > int err;
> > err = stop_machine_create();
> > if (err)
> > return err;
> > cpu_maps_update_begin();
> >
> > if (cpu_hotplug_disabled) {
> > err = -EBUSY;
> > goto out;
> > }
> >
> > cpu_clear(cpu, cpu_active_map);
> > /* ... */
> > synchronize_sched();
> > err = _cpu_down(cpu, 0);
> > if (cpu_online(cpu))
> > cpu_set(cpu, cpu_active_map);
> >
> > out:
> > cpu_maps_update_done();
> > stop_machine_destroy();
> > return err;
> > }
> >
> > The call to _cpu_down() is where we eventually get to the code
> > that my patch below touches, so you can see that we mark the CPU
> > as !active before we ever get to the step of migrating interrupts
> > (which relies on cpu_online_map).
> >
> > If RCU looked at cpu_active_map instead of cpu_online_map, it
> > seems like we would avoid the potential race situation you
> > mentioned earlier.
> >
> > Alternatively, I could explore just playing with the ia64
> > interrupt migration code to use cpu_active_mask instead, but
> > wanted to get your thoughts from the RCU perspective.
>
> Perhaps I am confused, but if the CPU is on its way down, doesn't RCU
> need a mask where the CPU's bit stays set longer rather than shorter?
>
> If I use cpu_active_mask, couldn't there be device interrupts during
> (for example) the synchronize_sched(), which might have RCU read-side
> critical sections that RCU needs to pay attention to?
Hm, I think you're right.
Thanks.
/ac
WARNING: multiple messages have this Message-ID (diff)
From: Alex Chiang <achiang@hp.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: tony.luck@intel.com, linux-ia64@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RCU can use cpu_active_map?
Date: Mon, 9 Feb 2009 15:50:00 -0700 [thread overview]
Message-ID: <20090209225000.GC3939@ldl.fc.hp.com> (raw)
In-Reply-To: <20090209213929.GQ6802@linux.vnet.ibm.com>
* Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> On Mon, Feb 09, 2009 at 01:13:45PM -0700, Alex Chiang wrote:
> > Paul,
> >
> > I don't pretend to understand RCU, but a very quick and naive
> > look through rcupreempt.c makes me think that we could use the
> > cpu_active_map instead of cpu_online_map?
> >
> > cpu_active_map was introduced by e761b772.
> >
> > In the CPU hotplug path, we touch the cpu_active_map very early
> > on:
> >
> > int __ref cpu_down(unsigned int cpu)
> > {
> > int err;
> > err = stop_machine_create();
> > if (err)
> > return err;
> > cpu_maps_update_begin();
> >
> > if (cpu_hotplug_disabled) {
> > err = -EBUSY;
> > goto out;
> > }
> >
> > cpu_clear(cpu, cpu_active_map);
> > /* ... */
> > synchronize_sched();
> > err = _cpu_down(cpu, 0);
> > if (cpu_online(cpu))
> > cpu_set(cpu, cpu_active_map);
> >
> > out:
> > cpu_maps_update_done();
> > stop_machine_destroy();
> > return err;
> > }
> >
> > The call to _cpu_down() is where we eventually get to the code
> > that my patch below touches, so you can see that we mark the CPU
> > as !active before we ever get to the step of migrating interrupts
> > (which relies on cpu_online_map).
> >
> > If RCU looked at cpu_active_map instead of cpu_online_map, it
> > seems like we would avoid the potential race situation you
> > mentioned earlier.
> >
> > Alternatively, I could explore just playing with the ia64
> > interrupt migration code to use cpu_active_mask instead, but
> > wanted to get your thoughts from the RCU perspective.
>
> Perhaps I am confused, but if the CPU is on its way down, doesn't RCU
> need a mask where the CPU's bit stays set longer rather than shorter?
>
> If I use cpu_active_mask, couldn't there be device interrupts during
> (for example) the synchronize_sched(), which might have RCU read-side
> critical sections that RCU needs to pay attention to?
Hm, I think you're right.
Thanks.
/ac
next prev parent reply other threads:[~2009-02-09 22:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 20:13 RCU can use cpu_active_map? Alex Chiang
2009-02-09 20:13 ` Alex Chiang
2009-02-09 21:39 ` Paul E. McKenney
2009-02-09 21:39 ` Paul E. McKenney
2009-02-09 22:50 ` Alex Chiang [this message]
2009-02-09 22:50 ` Alex Chiang
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=20090209225000.GC3939@ldl.fc.hp.com \
--to=achiang@hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tony.luck@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.