This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hashtable


David,

There are numerous problems with my hashtable approach. Besides raw
performance, it is not in any way better than the maps. A custom chunk
of code, tailored for a task will beat a generic library in a specific
test. I do not have anything to replace the maps. I do not have
anything generic enough worth adding to the SystemTap. No yet anyway.
A "map" which is fine tuned for thread ID key - this is an idea I am
considering.

I am playing with something I call "STAP bypass" - allow to register a
pure C implementation of a probe. This gives about 1% gain part of
which comes from removing calls to _stp_print_flush(). A define symbol
like STP_TRACE_OFF would be nice.

Unfortunately I doubt my employer is willing to spend my time
extending STAP functionality. The very opposite is true. I am trying
to minimise any STAP hacking unless I encounter an issue I can not
solve (begin and end probes are such an issue)

The only goal behind my mail below was to help anyone who is trying to
tackle a very specific corner case.



On Fri, Jul 14, 2017 at 6:35 PM, David Smith <dsmith@redhat.com> wrote:
> Arkady,
>
> If you think the existing systemtap maps have too much overhead, we'd
> welcome you to take a shot at reworking them. This could benefit all
> systemtap users. We welcome all contributors. You and/or your employer
> will need to be OK with you contributing code under the GPLv2 license.
>
> Take the existing systemtap source code and start replacing the
> existing map functionality with your improved map code. When redoing
> code like this, you'd want to make sure the existing map tests have
> the same results with your code as with the original code. We'd be
> happy to consult with you along the way.
>
> Let us know if you have questions or need pointers on where to look first.
>
>
> On Thu, Jul 13, 2017 at 11:51 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> For the WEB search sake
>>
>> This is a reply to the thread "25400 by: Arkady"
>>
>> The following code demonstrates about 20% improvement in the latency
>>
>> https://github.com/larytet/lockfree_hashtable
>
>
>
> --
> David Smith
> Principal Software Engineer
> Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]