[lkml]   [2011]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

    > 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.



     \ /
      Last update: 2011-05-18 01:03    [W:0.022 / U:3.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site