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


This simple script presents the problem when running on a multicore machine

#!/bin/bash

function echo_loop()
{
  file=echo_file_`date +%s%N`; echo $file; echo > $file;
counter=1;end=$((SECONDS+10)); while [ $SECONDS -lt $end ]; do echo
$counter >>$file; counter=$((counter+1)); done; tail -n 1 $file;rm -f
$file
}


CPUS=`grep -c ^processor /proc/cpuinfo`
pids=""
counter=0
while [  $counter -lt $CPUS ]; do
  echo_loop &
  pids="$pids $!"
  counter=$(($counter+1))
done

wait $pids

This short thing generates above 10M system calls/s on a 40 cores
machine.  I do  not know the exact rate because the performance
overhead of my STAP script exceeds 30%.

This rate represents a challenge for the system I develop. The system
collects system calls, copies the arguments to the shared memory.


On Fri, Jul 7, 2017 at 6:26 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> On Thu, Jul 6, 2017 at 9:24 PM, David Smith <dsmith@redhat.com> wrote:
>> OK, The first thing to do is run your script with 1 addition. Add
>> '-DSTP_ALIBI' to the stap command line. This will compile/run the
>> script, but when a probe is hit it will return immediately.
>>
>
> I have been through this routine including the -t flag.
> 10 empty probes introduce ~8% overhead
>
>> This will give you an idea of the overhead of kprobes itself.
>>
>> Another option would be to remove the '-DSTP_ALIBI' from the command
>> line and '-t' to the command line. Here's a description of what that
>> option does:
>>
>>        -t     Collect timing information on the number of times probe executes
>>               and average amount of time spent in each probe-point. Also shows
>>               the derivation for each probe-point.
>>
>> Once you've done that, we'll know more of what is going on.
>
> The heaviest probes are thread creation related. The following output
> is from the production code. The lines are ordered by MIN time.
>
> index   state      hits  min*     avg       max name
> │168     on            1 79908   79908     79908
> begin(-9223372036854775808)
> │  0     on            1 47496   47496     47496 begin
> │114     on           50 16065   70322    528451
> kernel.function("SyS_execve@/build/linux-EO9xOi/linux-4.4.0/fs/exec.c:1722").call
> │171     on            1 14337   14337     14337
> begin(-9223372036854775808)
> │172     on            1 13149   13149     13149
> begin(-9223372036854775808)
> │132     on            1  9525    9525      9525
> kernel.function("SyS_accept4@/build/linux-EO9xOi/linux-4.4.0/net/socket.c:1425").call
> │121     on            1  8628    8628      8628


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