fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<fche>
agentzh, re. that hash table, sure
<fche>
not sure all our uses of the table are rcu-compatible, so the spinlock might be unavoidable, but will consider
<agentzh>
fche: okay, cool, will proceed accordingly and propose patches here soon.
<fche>
great
<agentzh>
and there's another thing, what do you think of adding other kinds of filters to the task finder?
<fche>
such as?
<agentzh>
currently there's only the pid filter and the exe path filter.
<agentzh>
such as the gpid filter and mount file system filters.
<agentzh>
sorry, i mean mount namespace id fiter
<agentzh>
*filter
<agentzh>
there seems to pid namespace filter already?
<fche>
interesting, so processes within a given container?
<agentzh>
*seems to be
<agentzh>
yep
<agentzh>
mount namespace is better than pid for containers.
<fche>
plausible
<agentzh>
especially when the file path is relative to the container.
<agentzh>
gpid is for process group id.
<agentzh>
it's also common for apache and nginx.
<agentzh>
and postgrsql
<agentzh>
many multi-process apps.
<fche>
would you couple this with new variants of stap -x PID ?
<agentzh>
yes, i'm also thinking about this line.
<agentzh>
adding new options to stap and staprun.
<agentzh>
so you're good with that?
<agentzh>
we can propose patches for these too.
<agentzh>
currently stap's vma tracker is tracking too many processes at the same time, which leads to high CPU contention on that vma hash table's spinlocks.
<agentzh>
it's crazy.
<agentzh>
very obvious cpu spikes when running the stap tool.
<agentzh>
the kernel cpu flame graph shows 80% of the CPU is spent there.
<agentzh>
more than 80%
<fche>
that's crazy, is there a lot of fork/mmap activity going on?
<agentzh>
just a lot of live processes and threads.
<agentzh>
thousdans
<agentzh>
in production servers.
<agentzh>
not many forks or mmap activilities though.
<agentzh>
*activities
<fche>
hm then surprised of much ongoing vma tracker activity
<agentzh>
i can show you the flame graph
<agentzh>
a sec
<fche>
(by the way, over here we were talking about possibly exposing the vma tracker's contents to stap tapsets,
<fche>
so we could query the dso's mapped into processes, etc.)
<agentzh>
is it different from @vma and @cast?
<fche>
yeah to get an actual list of shared libraries / base addresses methinks
<fche>
not sure it's needed but may be
<agentzh>
i used to propose the @vma() operator patch to you.
<agentzh>
but it seems i never got the chance to commit it...
<agentzh>
@vma(addr, module)
<agentzh>
it converts relative address in a module to the absolute address.
<agentzh>
when there's no symbols or dwarf are incorrect.
<fche>
aha yeah
<agentzh>
if you're still open to it, we are happy to commit.
<agentzh>
with some docs and tests too.
<fche>
how about posting it, let others take a look
<agentzh>
sure, will post it here
<agentzh>
with a link
<agentzh>
email is more troublesome.
<fche>
or you could push the code to a new branch, and discuss it in email
<fche>
that's how some of us do feature work ehre
<agentzh>
yeah, that's fine too.
<agentzh>
will do.
<agentzh>
we don't really want to maintain these patches in our own branch.
<agentzh>
every time we wan to sync with the upstream repo, it's painful :)
<agentzh>
especially when you like to do big code refactoring from time to time.
<agentzh>
it's nightmare for us ;)
<fche>
understood
<agentzh>
btw, kerneltoast is preparing a Dl stapio hang bugfix patch these days.
<agentzh>
will be ready very soon as well.
<agentzh>
we'll need you review definitely.
<fche>
nice, you guys are doing good helpful work, thank you
<agentzh>
it's tricky.
<agentzh>
of course. and we're hiring more kernel developers to do more work :)