Re: [patch] x86/vsyscall: Add Kconfig option to use native vsyscalls,switch to it

[Andy Lutomirski]

On Tue, Nov 20, 2012 at 1:41 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
>> >      0.10%  [kernel]          [k] __do_page_fault
>> >      0.08%  [kernel]          [k] handle_mm_fault
>> >      0.08%  libjvm.so         [.] os::javaTimeMillis()
>> >      0.08%  [kernel]          [k] emulate_vsyscall
>>
>> Oh, finally a clue: you seem to have vsyscall emulation
>> overhead!
>>
>> Vsyscall emulation is fundamentally page fault driven - which
>> might explain why you are seeing page fault overhead. It might
>> also interact with other sources of faults - such as
>> numa/core's working set probing ...
>>
>> Many JVMs try to be smart with the vsyscall. As a test, does
>> the vsyscall=native boot option change the results/behavior in
>> any way?
>
> As a blind shot into the dark, does the attached patch help?
>
> If that's the root cause then it should measurably help mainline
> SPECjbb performance as well. It could turn numa/core from a
> regression into a win on your system.
>
> Thanks,
>
>         Ingo
>
> ----------------->
> Subject: x86/vsyscall: Add Kconfig option to use native vsyscalls, switch to it
> From: Ingo Molnar <mingo@xxxxxxxxxx>
>
> Apparently there's still plenty of systems out there triggering
> the vsyscall emulation page faults - causing hard to track down
> performance regressions on page fault intense workloads...
>
> Some people seem to have run into that with threading-intense
> Java workloads.
>
> So until there's a better solution to this, add a Kconfig switch
> to make the vsyscall mode configurable and turn native vsyscall
> support back on by default.
>

I'm not sure the default should be changed.  Presumably only a
smallish minority of users are affected, and all of their code still
*works* -- it's just a little bit slower.

>
> +config X86_VSYSCALL_COMPAT
> +       bool "vsyscall compatibility"
> +       default y
> +       help

This is IMO misleading.  Perhaps the option should be
X86_VSYSCALL_EMULATION.  A description like "compatibility" makes
turning it on sound like a no-brainer.

Perhaps the vsyscall emulation code should be tweaked to warn if it's
getting called more than, say, 1k times per second.  The kernel could
log something like "Detected large numbers of emulated vsyscalls.
Consider upgading, setting vsyscall=native, or adjusting
CONFIG_X86_WHATEVER."


> +         vsyscalls, as global executable pages, can be a security hole
> +         escallation helper by exposing an easy shell code target with

escalation?

> +         a predictable address.
> +
> +         Many versions of glibc rely on the vsyscall page though, so it
> +         cannot be eliminated unconditionally. If you disable this
> +         option these systems will still work but might incur the overhead
> +         of vsyscall emulation page faults.
> +
> +         The vsyscall=none, vsyscall=emulate, vsyscall=native kernel boot
> +         option can be used to override this mode as well.
> +
> +         Keeping this option enabled leaves the vsyscall page enabled,
> +         i.e. vsyscall=native. Disabling this option means vsyscall=emulate.
> +
> +         If unsure, say Y.
> +

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/