linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Mike Frysinger <vapier@gentoo.org>,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-sh@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	linux-kernel@vger.kernel.org,
	uclinux-dist-devel@blackfin.uclinux.org, linux-mm@kvack.org,
	Anton Vorontsov <anton.vorontsov@linaro.org>,
	Paul Mundt <lethal@linux-sh.org>,
	John Stultz <john.stultz@linaro.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Russell King <linux@arm.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2.1 01/10] cpu: Introduce clear_tasks_mm_cpumask() helper
Date: Mon, 26 Mar 2012 19:23:44 +0200	[thread overview]
Message-ID: <1332782624.16159.145.camel@twins> (raw)
In-Reply-To: <20120326170443.GA25229@redhat.com>

On Mon, 2012-03-26 at 19:04 +0200, Oleg Nesterov wrote:

> Interesting... Why? I mean, why do you dislike stop_machine() in
> _cpu_down() ? Just curious.

It disturbs all cpus, the -rt people don't like that their FIFO tasks
don't get to run, the trading people don't like their RDMA poll loops to
be interrupted.. etc.

Now arguably, one should simply not do hotplug crap while such things
are running, and mostly that's a perfectly fine constraint. But it
doesn't help that people view cpu hotplug as a power savings or resource
provisioning 'feature' and there's userspace daemons that plug
on-demand.

But my ultimate goal is to completely remove synchronization that is
actively machine wide, since we all know that as long as such stuff
exists people will want to use it.

Now I don't know we'll ever fully get there -- see the BKL saga -- but
its worth trying I think. The module unload and esp. the text_poke usage
of stop_machine are much worse offenders, since both those are
relatively common and much harder to avoid.

  reply	other threads:[~2012-03-26 18:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-24 10:26 [PATCH v2 0/10] Fixes for common mistakes w/ for_each_process and task->mm Anton Vorontsov
2012-03-24 10:27 ` [PATCH 01/10] cpu: Introduce clear_tasks_mm_cpumask() helper Anton Vorontsov
2012-03-24 12:43   ` Peter Zijlstra
2012-03-24 16:43     ` [PATCH v2.1 " Anton Vorontsov
2012-03-25 17:42       ` Oleg Nesterov
2012-03-26  7:59         ` Peter Zijlstra
2012-03-26 17:04           ` Oleg Nesterov
2012-03-26 17:23             ` Peter Zijlstra [this message]
2012-03-28  0:01         ` Benjamin Herrenschmidt
2012-03-24 10:28 ` [PATCH 02/10] arm: Use clear_tasks_mm_cpumask() Anton Vorontsov
2012-03-24 10:28 ` [PATCH 03/10] powerpc: " Anton Vorontsov
2012-03-24 10:28 ` [PATCH 04/10] sh: " Anton Vorontsov
2012-03-24 10:29 ` [PATCH 05/10] blackfin: A couple of task->mm handling fixes Anton Vorontsov
2012-03-24 10:30 ` [PATCH 06/10] blackfin: Fix possible deadlock in decode_address() Anton Vorontsov
2012-03-24 10:30 ` [PATCH 07/10] um: Should hold tasklist_lock while traversing processes Anton Vorontsov
2012-03-24 11:12   ` Richard Weinberger
2012-03-24 12:48   ` Peter Zijlstra
2012-03-24 16:43     ` Anton Vorontsov
2012-03-24 10:30 ` [PATCH 08/10] um: Fix possible race on task->mm Anton Vorontsov
2012-03-24 11:12   ` Richard Weinberger
2012-03-24 10:31 ` [PATCH 09/10] um: Properly check all process' threads for a live mm Anton Vorontsov
2012-03-24 11:12   ` Richard Weinberger
2012-03-24 10:31 ` [PATCH 10/10] oom: Make find_lock_task_mm() sparse-aware Anton Vorontsov
2012-03-24 12:52   ` Peter Zijlstra
2012-03-24 16:21     ` Anton Vorontsov
2012-03-24 16:43       ` Peter Zijlstra
2012-03-28  7:20     ` David Rientjes

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=1332782624.16159.145.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=anton.vorontsov@linaro.org \
    --cc=john.stultz@linaro.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oleg@redhat.com \
    --cc=richard@nod.at \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=vapier@gentoo.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;
as well as URLs for NNTP newsgroup(s).