Messages in this thread | | | Date | Wed, 18 May 2011 00:59:59 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH v4 0/6] Micro-optimize vclock_gettime |
| |
On Tue, 17 May 2011, Andi Kleen wrote: > 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
_ALL_ the statically linked programs? Point out a single one which matters and _IS_ performance critical.
> 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?
Which is completely irrelevant to x86_64. Point to a single relevant x86_64 embedded system to which one of the above handwaving applies.
> And then there are of course the old glibcs. A lot of people > (including me) use new kernels with old userland.
And how is your use case performance critical ?
Furthermore any halfways up to date deployemnt is using VDSO for obvious reasons and the archaic stuff which might be affected is not using a recent kernel at all (except for akpm on his retro laptop, but that "performance penalty" is probably the least of his worries).
> 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 --
It's not somewhat ugly. It's a design failure and more important it's a risk - and you very well know that.
> but compatibility (including performance compatibility) has always > been importand in Linux and we have far uglier code around in the > name of compatibility..
We have ugly code around, but it has always been more important to fix security risks than keeping them around for performance sake.
> And the "security problem" you keep talking about can be fixed much > easier and more compatible as I pointed out.
Unless you come forth with a patch which addresses _ALL_ reasons which caused me to remove your superior "Make the vsyscall less risky" approach, just admit that it's fcked up by design and be done with it.
Stop your "as I pointed out" handwaving please. That code was broken and even exploitable and I removed it for more than one very good reason. Stop claiming that your "design" is in any way fixable. It's not.
> As far as I'm concered the change is a bad idea.
As far as I'm concerned you seem to regain your old habits of defending your proven to be wrong "design" decisions no matter what.
And as long as you can't come up with documented proof that a single application is affected by such a change, STFU!
Even if you are not able to proof it, it's a total nobrainer to revert such a change and make it CONFIG_KEEP_FCKUP=y dependent in the very unliklely case that we get a proper and reasonable regression report.
Thanks,
tglx
| |