All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Andy Lutomirski <luto@MIT.EDU>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Borislav Petkov <bp@amd64.org>
Subject: Re: [PATCH v4 0/6] Micro-optimize vclock_gettime
Date: Tue, 17 May 2011 14:31:26 -0700	[thread overview]
Message-ID: <m2hb8typxt.fsf@firstfloor.org> (raw)
In-Reply-To: <4DD2BEFB.6070609@mit.edu> (Andy Lutomirski's message of "Tue, 17 May 2011 14:31:23 -0400")

Andy Lutomirski <luto@MIT.EDU> writes:
>
> On KVM on Sandy Bridge, I can emulate a vsyscall that does nothing in 400ns or so.  I'll try to make this code emulate real vsyscalls over the weekend.  This was much easier than I expected.

How about the performance of all the statically linked programs? I guess
you just declared they don't matter? gettimeofday is quite critical
and adding a exception into it is just a performance desaster.

Also it's always a dangerous assumption to think that all
programs on Linux use glibc ("all world is a Vax")

In fact more and more of Linux users are using different libcs these
days (like Android or embedded systems or languages with special runtime
systems) Who knows if all those other libraries use vDSO?

And then there are of course the old glibcs. A lot of people
(including me) use new kernels with old userland.

For me this seems like a very risky move -- breaking performance of
previously perfectly good set ups for very little reason.

Given the old vsyscall code is somewhat ugly -- I wouldn't argue that --
but compatibility (including performance compatibility) has always
been importand in Linux and we have far uglier code around in the name of 
compatibility..

And the "security problem" you keep talking about can be fixed
much easier and more compatible as I pointed out.

As far as I'm concered the change is a bad idea.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

  parent reply	other threads:[~2011-05-17 21:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16 16:00 [PATCH v4 0/6] Micro-optimize vclock_gettime Andy Lutomirski
2011-05-16 16:00 ` [PATCH v4 1/6] x86-64: Clean up vdso/kernel shared variables Andy Lutomirski
2011-05-16 17:23   ` Borislav Petkov
2011-05-16 17:34     ` Andrew Lutomirski
2011-05-16 16:00 ` [PATCH v4 2/6] x86-64: Remove unnecessary barrier in vread_tsc Andy Lutomirski
2011-05-16 16:01 ` [PATCH v4 3/6] x86-64: Don't generate cmov " Andy Lutomirski
2011-05-16 16:01 ` [PATCH v4 4/6] x86-64: vclock_gettime(CLOCK_MONOTONIC) can't ever see nsec < 0 Andy Lutomirski
2011-05-16 16:01 ` [PATCH v4 5/6] x86-64: Move vread_tsc into a new file with sensible options Andy Lutomirski
2011-05-16 16:01 ` [PATCH v4 6/6] x86-64: Turn off -pg and turn on -foptimize-sibling-calls for vDSO Andy Lutomirski
2011-05-16 16:09 ` [PATCH v4 0/6] Micro-optimize vclock_gettime Andi Kleen
2011-05-16 16:25   ` Thomas Gleixner
2011-05-16 16:49     ` Andi Kleen
2011-05-16 17:05       ` Andrew Lutomirski
2011-05-16 20:22         ` Andi Kleen
2011-05-16 21:28           ` Andrew Lutomirski
2011-05-16 21:53           ` Thomas Gleixner
2011-05-16 22:17             ` Andrew Lutomirski
2011-05-16 22:40               ` Thomas Gleixner
2011-05-17  8:00                 ` Ingo Molnar
2011-05-17 11:11                   ` Andrew Lutomirski
2011-05-17 11:36                     ` Ingo Molnar
2011-05-17 18:31                       ` Andy Lutomirski
2011-05-17 19:27                         ` Ingo Molnar
2011-05-17 21:31                         ` Andi Kleen [this message]
2011-05-17 22:59                           ` Thomas Gleixner
2011-05-18  3:18                             ` Andrew Lutomirski
2011-05-18  7:30                               ` Thomas Gleixner
2011-05-18  8:31                                 ` Ingo Molnar
2011-05-18 11:30                                   ` Andrew Lutomirski
2011-05-18 12:10                                     ` Ingo Molnar
2011-05-17  7:56       ` Ingo Molnar

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=m2hb8typxt.fsf@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=bp@amd64.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@MIT.EDU \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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 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.