All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Krasnyanskiy <maxk@qualcomm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jason Baron <jbaron@redhat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [patch 1/2] add ALL_CPUS option to stop_machine_run()
Date: Fri, 29 Feb 2008 10:24:13 -0800	[thread overview]
Message-ID: <47C84DCD.5040803@qualcomm.com> (raw)
In-Reply-To: <20080229090050.GA19519@elte.hu>

Ingo Molnar wrote:
> * Max Krasnyanskiy <maxk@qualcomm.com> wrote:
> 
>>> -allow stop_mahcine_run() to call a function on all cpus. Calling 
>>> stop_machine_run() with a 'ALL_CPUS' invokes this new behavior.
>>>  stop_machine_run() proceeds as normal until the calling cpu has 
>>>  invoked 'fn'. Then, we tell all the other cpus to call 'fn'.
>> Jason, we're actually trying to reduce the usage of the stop_machine 
>> in general. [...]
> 
> please talk in your own name. Stop-machine is a very elegant tool that 
> simplifies a lot of hard things in the kernel and is reasonably fast as 
> well. We've just recently added two new usages of it and more are 
> planned.
> 
> _you_ might be the one who wants to 'reduce the usage of stop_machine' - 
> but that means it is _you_ who first has to convert a number of very 
> difficult pieces of code to "something else".
Sure I started the discussion but I suppose you missed Andi's and other 
replies. All I said that people should think twice before relying on it.
btw I'm ok if I _am_ the _one_ who has to convert those pieces of code, that's 
part of the fun :). But if people keep adding stuff which uses stom_machine 
that may be pretty difficult :).

btw Being an RT guy you do not think that stop machine is evil ? I mean from 
the overhead and especially latency perspective. By overhead I mean if you 
have 100+ cpu box that Paul and other guys have mentioned here. Every single 
CPU has to be frozen. You said it's reasonably fast. I guess it depends what's 
reasonable. And from the latency perspective all bets are off. We have no 
guaranties whatsoever as to hold long it will take for cpu X to get frozen 
(there numerous factors here) and all the other cpus have to wait for it.
As I said for some things there is just no other way but to use the 
stop_machine but we should try to minimize that as much as possible.

Max


  reply	other threads:[~2008-02-29 18:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-02 21:08 [patch 0/7] Immediate Values Mathieu Desnoyers
2008-02-02 21:08 ` [patch 1/7] Immediate Values - Architecture Independent Code Mathieu Desnoyers
2008-02-26 22:52   ` Jason Baron
2008-02-26 23:12     ` Mathieu Desnoyers
2008-02-26 23:34       ` Mathieu Desnoyers
2008-02-27 16:44         ` Jason Baron
2008-02-27 17:01       ` Jason Baron
2008-02-27 19:05     ` Mathieu Desnoyers
2008-02-28 16:33       ` [patch 1/2] add ALL_CPUS option to stop_machine_run() Jason Baron
2008-02-28 22:09         ` Max Krasnyanskiy
2008-02-28 22:14           ` Mathieu Desnoyers
2008-02-29  2:39             ` Jason Baron
2008-02-29  9:00           ` Ingo Molnar
2008-02-29 18:24             ` Max Krasnyanskiy [this message]
2008-02-29 19:15               ` Ingo Molnar
2008-02-29 19:58                 ` Max Krasnyanskiy
2008-03-03  4:12                 ` Rusty Russell
2008-03-04  0:30                   ` Max Krasnyanskiy
2008-03-04  2:36                     ` Rusty Russell
2008-03-04  4:11                       ` Max Krasnyansky
2008-03-02 23:32           ` Rusty Russell
2008-02-28 16:37       ` [patch 2/2] implement immediate updating via stop_machine_run() Jason Baron
2008-02-29 13:43         ` Mathieu Desnoyers
2008-02-28 16:50       ` [patch 1/7] Immediate Values - Architecture Independent Code Jason Baron
2008-02-02 21:08 ` [patch 2/7] Immediate Values - Kconfig menu in EMBEDDED Mathieu Desnoyers
2008-02-02 21:08 ` [patch 3/7] Immediate Values - x86 Optimization Mathieu Desnoyers
2008-02-02 21:08 ` [patch 4/7] Add text_poke and sync_core to powerpc Mathieu Desnoyers
2008-02-02 21:08 ` [patch 5/7] Immediate Values - Powerpc Optimization Mathieu Desnoyers
2008-02-02 21:08 ` [patch 6/7] Immediate Values - Documentation Mathieu Desnoyers
2008-02-02 21:08 ` [patch 7/7] Scheduler Profiling - Use Immediate Values Mathieu Desnoyers

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=47C84DCD.5040803@qualcomm.com \
    --to=maxk@qualcomm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    /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.