Re: SIGSEGV in LuaJIT 2.1 VM
- From: Igor Ehrlich <igor.a.ehrlich@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 23 Nov 2016 05:42:27 +0300
That's ... surprising. If my patch is indeed a cure, then I must admit that
I don't fully understand why it is a cure.
... cause of the longer latency? :D
What about that thread affinity Igor suggested, does that have any
advantages over Peter’s magic one-liner? :)
These are different solutions. Peter proposes a fix to the LuaJIT, which is
a 3rdparty for you. Implementing thread affinity is a re-design of your
application, not the libraries you are using. As Peter said, it might make
your performance either better or worse (usually, either WAY better or WAY
worse), while also fixing this issue. Anyway. it's quite a long shot.
On Wed, Nov 23, 2016 at 3:08 AM, Peter Cawley <corsix@xxxxxxxxxx> wrote:
On Tue, Nov 22, 2016 at 11:48 AM, Tomas Kvasnicka <nzt4567@xxxxxxx> wrote:
Peter, I’ve taken a look at some of the core files and checked the
faulting-rip values. It’s always unique - e.g. 0x834c87b % 256 == 123,
0x14066216 % 256 == 22, 0x1ff339bf % 256 == 191, 0x3e4a1d0 % 256 == 208,
0x9c66f99 % 256 == 153, 0x19cc4e1a % 256 == 26, …
Oh well, so much for that theory.
As of now there are several machines running successfully with Peter’s
patch without crashing (so far).
That's ... surprising. If my patch is indeed a cure, then I must admit
that I don't fully understand why it is a cure.
Are there any drawbacks of using that solution permanently?
You pay an extra function call and extra cpuid instruction every time
a new trace is created and every time a new side trace is patched into
a parent trace and every time an FFI callback is created. When wearing
my low-latency hat, cpuid falls into the category of outrageously slow
instructions that should never be executed, but given the surroundings
of machine code generation and multiple mprotect calls, you probably
won't notice an extra cpuid. Other than possibly suppressing weird CPU
behaviour and slowing the code down a little bit, you shouldn't
observe any side effects from the extra cpuid.
What about that thread affinity Igor suggested, does that have any
advantages over Peter’s magic one-liner? :)
You might find that pinning each of your threads to exactly one CPU
core has performance benefits for your application (or you might find
that it massively degrades performance). Pinning has the benefit that
you can do it without modifying and recompiling the LuaJIT source
(though you seem happy to modify it, so that point is slightly moot).
And finally, should this eventually make it’s way to the main branch and
save other innocent people from this suffering? :)
If it is a cure, then probably yes, though personally I'd like to
better understand why it has the effects it does rather than
committing it out of superstition.
Other related posts:
