You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a note for posterity, glibc directly invokes futex; there's no unresolved symbol we can preload on top of. So we can't buffer it with our current approach. Shame.
I would guess that pthread_mutex_{lock, unlock} and cond_wait would get us the vast vast majority. Doing that is a little scary and nontrivial though. But it's relatively easy to quantify how worth doing it would be once we have the structure in place.
There are two measures that are interesting here: first is raw syscall count, which is easy to measure. The second is syscalls that "break the chain". For example, if gettimeofday is one of the top syscalls, we should buffer it, but if 1/3 of the time it's followed by stat say, then the buffering won't be as effective. We'd want to buffer stat too.
This pretty much matches historical data. Unfortunately futex and socketcall are giant pains in the butt to support, but looks like we'll want to. The rest are trivial though.
The desched event, which was working so well in early testing, ain't doing so well with FF. I added wrappers for the easy syscalls above (futex, socketcall, and fcntl are hard), and FF blows up. However, when I was able to get a run that avoided the landmines, FF recorded about 10% faster just from wrapping poll (loading the start page). That's good news.
The wrapper for open also doesn't seem to be working all the time. rr ends up processing a significant number of open syscalls, even though we do sometimes hit the open wrapper, and the buffer isn't full. Needs investigation. However, even without wrapping all the open calls, FF is about 5% faster with the wrapper. That's also great news.
The desched event turned out to still be working just fine, only a recent commit regressed it embarrassingly. I guess that's what happens when effectively dead code is committed. The basic syscalls above, sans poll too now, are working. Just needs some cleanup before commit. poll is proving to be a bit of a pain, and the work here is starting to pile up, so splitting that out into a followup.
Activity
rocallahan commentedon May 8, 2013
It's easy to collect counts of the number of syscalls by reading the rr trace files, especially for non-wrapped syscalls which are recorded in ASCII.
joneschrisg commentedon Jun 28, 2013
As a note for posterity, glibc directly invokes futex; there's no unresolved symbol we can preload on top of. So we can't buffer it with our current approach. Shame.
rocallahan commentedon Jun 28, 2013
Any idea which symbols/how many symbols we'd need to override via LD_PRELOAD to catch most futex traffic?
joneschrisg commentedon Jun 28, 2013
I would guess that pthread_mutex_{lock, unlock} and cond_wait would get us the vast vast majority. Doing that is a little scary and nontrivial though. But it's relatively easy to quantify how worth doing it would be once we have the structure in place.
joneschrisg commentedon Jul 12, 2013
There are two measures that are interesting here: first is raw syscall count, which is easy to measure. The second is syscalls that "break the chain". For example, if
gettimeofdayis one of the top syscalls, we should buffer it, but if 1/3 of the time it's followed bystatsay, then the buffering won't be as effective. We'd want to bufferstattoo.joneschrisg commentedon Jul 12, 2013
On a small representative Firefox workflow, histogram-trace says the top 10 are
This pretty much matches historical data. Unfortunately
futexandsocketcallare giant pains in the butt to support, but looks like we'll want to. The rest are trivial though.joneschrisg commentedon Jul 12, 2013
This seems to be coming from a *Monkey [1] JIT. So not so surprising.
[1] I just realized I don't know what monkey FF is on anymore! sniffle
joneschrisg commentedon Jul 12, 2013
The desched event, which was working so well in early testing, ain't doing so well with FF. I added wrappers for the easy syscalls above (futex, socketcall, and fcntl are hard), and FF blows up. However, when I was able to get a run that avoided the landmines, FF recorded about 10% faster just from wrapping
poll(loading the start page). That's good news.The wrapper for
openalso doesn't seem to be working all the time. rr ends up processing a significant number ofopensyscalls, even though we do sometimes hit theopenwrapper, and the buffer isn't full. Needs investigation. However, even without wrapping all the open calls, FF is about 5% faster with the wrapper. That's also great news.joneschrisg commentedon Jul 15, 2013
The desched event turned out to still be working just fine, only a recent commit regressed it embarrassingly. I guess that's what happens when effectively dead code is committed. The basic syscalls above, sans
polltoo now, are working. Just needs some cleanup before commit.pollis proving to be a bit of a pain, and the work here is starting to pile up, so splitting that out into a followup.joneschrisg commentedon Jul 16, 2013
Testing shows that
closeandwritevmight be worth buffering. The latter is used by xlib, IIRC.The last two tests; Not yet fixed, still failing if enabled.
The last two tests; Not yet fixed, still failing if enabled.
The last two tests; Not yet fixed, still failing if enabled.
The last two tests; Not yet fixed, still failing if enabled.
The last two tests; Not yet fixed, still failing if enabled.
Run asan-enabled test and test clone_cleartid_coredump with detect_le…