From: Rusty Russell <rusty@rustcorp.com.au>
To: Keith Owens <kaos@ocs.com.au>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
Len Brown <len.brown@intel.com>
Subject: Re: Is stopmachine() preempt safe?
Date: Mon, 28 Aug 2006 19:21:18 +1000 [thread overview]
Message-ID: <1156756878.10467.94.camel@localhost.localdomain> (raw)
In-Reply-To: <10518.1156747016@kao2.melbourne.sgi.com>
On Mon, 2006-08-28 at 16:36 +1000, Keith Owens wrote:
> There is a lot of code in the kernel that runs cpu_online_map without
> taking any locks and without disabling preemption. Obviously we do not
> want all that code to lock or disable preemption, it will kill
> scalability.
There is actually not much code which should use cpu_online_map. Code
which does must be careful: you generally need to think about handling
cpu hotplug notifiers as well as the map changing underneath you.
Doing a brief audit, ignoring the already-acknowledged cpufreq code and
arch-specifics, I can see these cases which seem suspicious:
./drivers/acpi/processor_core.c:acpi_processor_handle_eject()
- I assume this is relying on some other mechanism so the cpu
doesn't get onlined?
- A couple of other num_online_cpus() there in ACPI might need a
rethink for hotplug CPU though.
./kernel/irq/proc.c: irq_affinity_write_proc()
- seems complicated, but I think migration.c handles when cpus
gone offline?
./drivers/oprofile/cpu_buffer.c:
- needs to handle hotplug cpus (or just say don't do that?)
./drivers/infiniband/hw/ipath/ipath_file_ops.c:
- seems to be using num_online_cpus as a really poor heuristic,
and incorrectly (for i = 0; i < num_online_cpus(); i++) <-- i is
not a valid CPU number!).
./kernel/power/main.c:suspend_prepare()
- suspicious, code here, too.
./net/core/dev.c: net_dma_rebalance()
- This is a heuristic, which may be OK.
./net/core/dev.c: softnet_get_online()
- It'd be nice if net/dev/core.c used cpu_possible() not
cpu_online() to report stats, so they don't get lost from
offlined CPUs.
./net/core/pktgen.c: pg_init()
- Assumes no CPU plugging, but is a pretty specialized driver.
(Other uses get away with being in initcalls, or on platforms without
hotplug CPU).
Disappointingly, none of these would be fixed by changing the semantics
of stop_machine; they rely on the online cpus and must take action when
they change, whether they are reading the online_cpu_map at the time or
not.
Rusty.
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
prev parent reply other threads:[~2006-08-28 9:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-27 9:42 Is stopmachine() preempt safe? Keith Owens
2006-08-27 23:38 ` Rusty Russell
2006-08-28 2:55 ` Keith Owens
2006-08-28 6:17 ` Rusty Russell
2006-08-28 6:36 ` Keith Owens
2006-08-28 9:21 ` Rusty Russell [this message]
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=1156756878.10467.94.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=kaos@ocs.com.au \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.