From: Stephane Eranian <eranian@hpl.hp.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Andi Kleen <ak@muc.de>, Arjan van de Ven <arjan@infradead.org>,
Andrew Morton <akpm@osdl.org>, Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, benh@kernel.crashing.org,
paulus@samba.org, stephane.eranian@hp.com
Subject: Re: + perfmon2-reserve-system-calls.patch added to -mm tree
Date: Tue, 15 Nov 2005 07:49:05 -0800 [thread overview]
Message-ID: <20051115154905.GC24983@frankl.hpl.hp.com> (raw)
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F04F630BF@scsmsx401.amr.corp.intel.com>
tony,
On Tue, Nov 15, 2005 at 07:28:35AM -0800, Luck, Tony wrote:
>
> >> Either way, either the emulation is in the kernel or it's not. If it's
> >> there (like it is now) it deserves maintenance. If it's not, it should
> >> be removed from the tree, since the only thing it's otherwise good for
> >> is potential security holes.
> >
> >I suppose it's still useful for all current IA64 users (Montecito
> >is not shipping yet and older CPUs support x86 in hardware) who don't like
> >binary only software.
>
> I was planning on asking who still depends on the emulation code
> a while after Montecito is shipping. Until then I'll try to do
> what makes sense in keeping the ia32 emulation system call table
> up to date.
>
> The perfmon syscalls would be an example of something that should
> *NOT* go into the ia32 emulation syscall table. It makes no sense
> whatever to put them there. I don't believe that the h/w emulation
> provides any performance counter emulation, and even if it did a
> user who cared about the performance of their application would do
> far better to re-compile it as native ia64 than to mess around
> trying to optimize their x86 binary.
>
I agree. The PMU between, let's a P4, and IA-64 is totally
different. It does not make sense to try and emulate the P4
PMU on an Ia-64 system. Similarly, it does not make sense
to develop a monitoring tool for IA-64 compiled in X86 mode
and relying on the emulation layer.
The only thing we need to ensure is that those system calls
don't do anything, i.e., if ever invoked in IA-32 HW emulation
they would need to go to sys_ni().
--
-Stephane
next prev parent reply other threads:[~2005-11-15 15:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 15:28 Luck, Tony
2005-11-15 15:49 ` Stephane Eranian [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-11-15 16:58 Luck, Tony
[not found] <200511142329.jAENTfmS004600@shell0.pdx.osdl.net>
2005-11-14 23:50 ` Arnd Bergmann
2005-11-15 0:04 ` Paul Mackerras
2005-11-15 0:09 ` Stephane Eranian
2005-11-15 1:12 ` Andrew Morton
2005-11-15 8:00 ` Stephane Eranian
2005-11-15 8:08 ` Arjan van de Ven
2005-11-15 13:40 ` Andi Kleen
2005-11-15 9:06 ` Christoph Hellwig
2005-11-16 10:24 ` Stephane Eranian
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=20051115154905.GC24983@frankl.hpl.hp.com \
--to=eranian@hpl.hp.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=stephane.eranian@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®