From: Avi Kivity <avi@qumranet.com>
To: Satyam Sharma <satyam.sharma@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org,
KVM <kvm-devel@lists.sourceforge.net>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 17/20] SMP: Implement on_cpu()
Date: Wed, 11 Jul 2007 10:26:30 +0300 [thread overview]
Message-ID: <46948626.6050308@qumranet.com> (raw)
In-Reply-To: <a781481a0707101707w121da1b7hc82dc0e3638e4570@mail.gmail.com>
Satyam Sharma wrote:
>
> And I think what's proposed is:
>
> 1. Change smp_call_function() semantics, to run given function
> on _all_ CPUs (thus getting rid of the on_each_cpu() "mistake")
>
> 2. Resort to (most probably implement another function?) using
> smp_call_function_mask() or flags appropriately to also serve
> the use cases where we need to run a given function on all
> _other_ CPUs
>
> Does this pointless/gratuitous code-churn really make sense?
> Definitely not to me ...
It's not proposed. Andi mentioned it in passing. The only churn is in
this thread.
>
> [ For the _single() case we now have on_cpu() as you originally
> proposed, which I definitely like and fills the other gap in the API. ]
>
> So I still don't quite understand what is the need to change existing
> semantics of smp_call_function{_single} in the first place.
>
I imagine Andi's motivation was that most uses benefit from this change,
and the rest don't suffer. It's better not to have a proliferation of
ever-so-similar APIs.
--
error compiling committee.c: too many arguments to function
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Satyam Sharma <satyam.sharma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: KVM <kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 17/20] SMP: Implement on_cpu()
Date: Wed, 11 Jul 2007 10:26:30 +0300 [thread overview]
Message-ID: <46948626.6050308@qumranet.com> (raw)
In-Reply-To: <a781481a0707101707w121da1b7hc82dc0e3638e4570-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Satyam Sharma wrote:
>
> And I think what's proposed is:
>
> 1. Change smp_call_function() semantics, to run given function
> on _all_ CPUs (thus getting rid of the on_each_cpu() "mistake")
>
> 2. Resort to (most probably implement another function?) using
> smp_call_function_mask() or flags appropriately to also serve
> the use cases where we need to run a given function on all
> _other_ CPUs
>
> Does this pointless/gratuitous code-churn really make sense?
> Definitely not to me ...
It's not proposed. Andi mentioned it in passing. The only churn is in
this thread.
>
> [ For the _single() case we now have on_cpu() as you originally
> proposed, which I definitely like and fills the other gap in the API. ]
>
> So I still don't quite understand what is the need to change existing
> semantics of smp_call_function{_single} in the first place.
>
I imagine Andi's motivation was that most uses benefit from this change,
and the rest don't suffer. It's better not to have a proliferation of
ever-so-similar APIs.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
next prev parent reply other threads:[~2007-07-11 7:26 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-08 11:54 [PATCH 00/20] KVM updates for 2.6.23, part 2 Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 01/20] KVM: Implement emulation of "pop reg" instruction (opcode 0x58-0x5f) Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 02/20] KVM: Implement emulation of instruction "ret" (opcode 0xc3) Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 03/20] KVM: Adds support for in-kernel mmio handlers Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 04/20] KVM: VMX: Fix interrupt checking on lightweight exit Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 05/20] KVM: Add support for in-kernel pio handlers Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 06/20] KVM: Fix x86 emulator writeback Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 07/20] KVM: Avoid useless memory write when possible Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 08/20] KVM: VMX: Reinitialize the real-mode tss when entering real mode Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 09/20] KVM: MMU: Fix Wrong tlb flush order Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 12:21 ` Ingo Molnar
2007-07-08 12:21 ` Ingo Molnar
2007-07-08 12:42 ` Avi Kivity
2007-07-08 12:42 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 10/20] KVM: VMX: Remove unnecessary code in vmx_tlb_flush() Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 11/20] KVM: SVM: Reliably detect if SVM was disabled by BIOS Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 13:43 ` Roland Dreier
2007-07-08 13:43 ` Roland Dreier
2007-07-08 13:45 ` Avi Kivity
2007-07-08 13:45 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 12/20] KVM: Remove kvmfs in favor of the anonymous inodes source Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 13/20] KVM: Clean up #includes Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 14/20] HOTPLUG: Add CPU_DYING notifier Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 15/20] HOTPLUG: Adapt cpuset hotplug callback to CPU_DYING Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 16/20] HOTPLUG: Adapt thermal throttle " Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 17/20] SMP: Implement on_cpu() Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 19:06 ` Andi Kleen
2007-07-09 6:46 ` Avi Kivity
2007-07-09 6:46 ` Avi Kivity
2007-07-09 7:16 ` Andi Kleen
2007-07-09 7:16 ` Andi Kleen
2007-07-09 9:40 ` Avi Kivity
2007-07-09 11:28 ` Avi Kivity
2007-07-09 11:28 ` Avi Kivity
2007-07-09 19:24 ` Satyam Sharma
2007-07-09 19:24 ` Satyam Sharma
2007-07-10 6:03 ` Avi Kivity
2007-07-10 6:03 ` Avi Kivity
2007-07-10 9:22 ` Satyam Sharma
2007-07-10 9:22 ` Satyam Sharma
2007-07-10 11:03 ` Avi Kivity
2007-07-11 0:07 ` Satyam Sharma
2007-07-11 0:07 ` Satyam Sharma
2007-07-11 7:26 ` Avi Kivity [this message]
2007-07-11 7:26 ` Avi Kivity
2007-07-11 7:47 ` Satyam Sharma
2007-07-11 7:47 ` Satyam Sharma
2007-07-11 9:43 ` gcc + kvm + 64 bit ? confused :-/ Benjamin Budts
2007-07-11 9:43 ` Benjamin Budts
2007-07-11 9:47 ` [kvm-devel] " Avi Kivity
2007-07-11 9:47 ` Avi Kivity
2007-07-11 10:54 ` Andi Kleen
2007-07-11 10:54 ` Andi Kleen
2007-07-08 11:54 ` [PATCH 18/20] KVM: Keep track of which cpus have virtualization enabled Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 19/20] KVM: Tune hotplug/suspend IPIs Avi Kivity
2007-07-08 11:54 ` Avi Kivity
2007-07-08 11:54 ` [PATCH 20/20] KVM: Use CPU_DYING for disabling virtualization Avi Kivity
2007-07-08 11:54 ` Avi Kivity
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=46948626.6050308@qumranet.com \
--to=avi@qumranet.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=satyam.sharma@gmail.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.