1. 10 11月, 2019 1 次提交
    • Z
      tracing: Fix "gfp_t" format for synthetic events · fa18f803
      Zhengjun Xing 提交于
      [ Upstream commit 9fa8c9c647be624e91b09ecffa7cd97ee0600b40 ]
      
      In the format of synthetic events, the "gfp_t" is shown as "signed:1",
      but in fact the "gfp_t" is "unsigned", should be shown as "signed:0".
      
      The issue can be reproduced by the following commands:
      
      echo 'memlatency u64 lat; unsigned int order; gfp_t gfp_flags; int migratetype' > /sys/kernel/debug/tracing/synthetic_events
      cat  /sys/kernel/debug/tracing/events/synthetic/memlatency/format
      
      name: memlatency
      ID: 2233
      format:
              field:unsigned short common_type;       offset:0;       size:2; signed:0;
              field:unsigned char common_flags;       offset:2;       size:1; signed:0;
              field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
              field:int common_pid;   offset:4;       size:4; signed:1;
      
              field:u64 lat;  offset:8;       size:8; signed:0;
              field:unsigned int order;       offset:16;      size:4; signed:0;
              field:gfp_t gfp_flags;  offset:24;      size:4; signed:1;
              field:int migratetype;  offset:32;      size:4; signed:1;
      
      print fmt: "lat=%llu, order=%u, gfp_flags=%x, migratetype=%d", REC->lat, REC->order, REC->gfp_flags, REC->migratetype
      
      Link: http://lkml.kernel.org/r/20191018012034.6404-1-zhengjun.xing@linux.intel.comReviewed-by: NTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: NZhengjun Xing <zhengjun.xing@linux.intel.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fa18f803
  2. 12 10月, 2019 1 次提交
    • T
      tracing: Make sure variable reference alias has correct var_ref_idx · e010c983
      Tom Zanussi 提交于
      commit 17f8607a1658a8e70415eef67909f990d13017b5 upstream.
      
      Original changelog from Steve Rostedt (except last sentence which
      explains the problem, and the Fixes: tag):
      
      I performed a three way histogram with the following commands:
      
      echo 'irq_lat u64 lat pid_t pid' > synthetic_events
      echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events
      echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function == 0xffffffff81200580' > events/timer/hrtimer_start/trigger
      echo 'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid) if common_flags & 1' > events/sched/sched_waking/trigger
      echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' > events/synthetic/irq_lat/trigger
      echo 'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)' > events/sched/sched_switch/trigger
      echo 1 > events/synthetic/wake_lat/enable
      
      Basically I wanted to see:
      
       hrtimer_start (calling function tick_sched_timer)
      
      Note:
      
        # grep tick_sched_timer /proc/kallsyms
      ffffffff81200580 t tick_sched_timer
      
      And save the time of that, and then record sched_waking if it is called
      in interrupt context and with the same pid as the hrtimer_start, it
      will record the latency between that and the waking event.
      
      I then look at when the task that is woken is scheduled in, and record
      the latency between the wakeup and the task running.
      
      At the end, the wake_lat synthetic event will show the wakeup to
      scheduled latency, as well as the irq latency in from hritmer_start to
      the wakeup. The problem is that I found this:
      
                <idle>-0     [007] d...   190.485261: wake_lat: lat=27 irqlat=190485230 pid=698
                <idle>-0     [005] d...   190.485283: wake_lat: lat=40 irqlat=190485239 pid=10
                <idle>-0     [002] d...   190.488327: wake_lat: lat=56 irqlat=190488266 pid=335
                <idle>-0     [005] d...   190.489330: wake_lat: lat=64 irqlat=190489262 pid=10
                <idle>-0     [003] d...   190.490312: wake_lat: lat=43 irqlat=190490265 pid=77
                <idle>-0     [005] d...   190.493322: wake_lat: lat=54 irqlat=190493262 pid=10
                <idle>-0     [005] d...   190.497305: wake_lat: lat=35 irqlat=190497267 pid=10
                <idle>-0     [005] d...   190.501319: wake_lat: lat=50 irqlat=190501264 pid=10
      
      The irqlat seemed quite large! Investigating this further, if I had
      enabled the irq_lat synthetic event, I noticed this:
      
                <idle>-0     [002] d.s.   249.429308: irq_lat: lat=164968 pid=335
                <idle>-0     [002] d...   249.429369: wake_lat: lat=55 irqlat=249429308 pid=335
      
      Notice that the timestamp of the irq_lat "249.429308" is awfully
      similar to the reported irqlat variable. In fact, all instances were
      like this. It appeared that:
      
        irqlat=$irqlat
      
      Wasn't assigning the old $irqlat to the new irqlat variable, but
      instead was assigning the $irqts to it.
      
      The issue is that assigning the old $irqlat to the new irqlat variable
      creates a variable reference alias, but the alias creation code
      forgets to make sure the alias uses the same var_ref_idx to access the
      reference.
      
      Link: http://lkml.kernel.org/r/1567375321.5282.12.camel@kernel.org
      
      Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
      Cc: linux-rt-users <linux-rt-users@vger.kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: 7e8b88a3 ("tracing: Add hist trigger support for variable reference aliases")
      Reported-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NTom Zanussi <zanussi@kernel.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e010c983
  3. 19 6月, 2019 1 次提交
  4. 24 3月, 2019 1 次提交
    • T
      tracing: Use strncpy instead of memcpy for string keys in hist triggers · ebca08d7
      Tom Zanussi 提交于
      commit 9f0bbf3115ca9f91f43b7c74e9ac7d79f47fc6c2 upstream.
      
      Because there may be random garbage beyond a string's null terminator,
      it's not correct to copy the the complete character array for use as a
      hist trigger key.  This results in multiple histogram entries for the
      'same' string key.
      
      So, in the case of a string key, use strncpy instead of memcpy to
      avoid copying in the extra bytes.
      
      Before, using the gdbus entries in the following hist trigger as an
      example:
      
        # echo 'hist:key=comm' > /sys/kernel/debug/tracing/events/sched/sched_waking/trigger
        # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist
      
        ...
      
        { comm: ImgDecoder #4                      } hitcount:        203
        { comm: gmain                              } hitcount:        213
        { comm: gmain                              } hitcount:        216
        { comm: StreamTrans #73                    } hitcount:        221
        { comm: mozStorage #3                      } hitcount:        230
        { comm: gdbus                              } hitcount:        233
        { comm: StyleThread#5                      } hitcount:        253
        { comm: gdbus                              } hitcount:        256
        { comm: gdbus                              } hitcount:        260
        { comm: StyleThread#4                      } hitcount:        271
      
        ...
      
        # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep gdbus | wc -l
        51
      
      After:
      
        # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep gdbus | wc -l
        1
      
      Link: http://lkml.kernel.org/r/50c35ae1267d64eee975b8125e151e600071d4dc.1549309756.git.tom.zanussi@linux.intel.com
      
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: 79e577cb ("tracing: Support string type key properly")
      Signed-off-by: NTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebca08d7
  5. 14 11月, 2018 1 次提交
  6. 20 10月, 2018 2 次提交
  7. 17 8月, 2018 1 次提交
  8. 11 8月, 2018 1 次提交
  9. 04 7月, 2018 1 次提交
  10. 29 5月, 2018 1 次提交
  11. 27 4月, 2018 3 次提交
    • T
      tracing: Add field modifier parsing hist error for hist triggers · dcf23457
      Tom Zanussi 提交于
      If the user specifies an invalid field modifier for a hist trigger,
      the current code correctly flags that as an error, but doesn't tell
      the user what happened.
      
      Fix this by invoking hist_err() with an appropriate message when
      invalid modifiers are specified.
      
      Before:
      
        # echo 'hist:keys=pid:ts0=common_timestamp.junkusecs' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
        -su: echo: write error: Invalid argument
        # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist
      
      After:
      
        # echo 'hist:keys=pid:ts0=common_timestamp.junkusecs' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
        -su: echo: write error: Invalid argument
        # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist
        ERROR: Invalid field modifier: junkusecs
          Last command: keys=pid:ts0=common_timestamp.junkusecs
      
      Link: http://lkml.kernel.org/r/b043c59fa79acd06a5f14a1d44dee9e5a3cd1248.1524790601.git.tom.zanussi@linux.intel.comSigned-off-by: NTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      dcf23457
    • T
      tracing: Add field parsing hist error for hist triggers · 5ec432d7
      Tom Zanussi 提交于
      If the user specifies a nonexistent field for a hist trigger, the
      current code correctly flags that as an error, but doesn't tell the
      user what happened.
      
      Fix this by invoking hist_err() with an appropriate message when
      nonexistent fields are specified.
      
      Before:
      
        # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
        -su: echo: write error: Invalid argument
        # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
      
      After:
      
        # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
        -su: echo: write error: Invalid argument
        # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
        ERROR: Couldn't find field: pid
          Last command: keys=pid:ts0=common_timestamp.usecs
      
      Link: http://lkml.kernel.org/r/fdc8746969d16906120f162b99dd71c741e0b62c.1524790601.git.tom.zanussi@linux.intel.comSigned-off-by: NTom Zanussi <tom.zanussi@linux.intel.com>
      Reported-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      5ec432d7
    • T
      tracing: Restore proper field flag printing when displaying triggers · 608940da
      Tom Zanussi 提交于
      The flag-printing code used when displaying hist triggers somehow got
      dropped during refactoring of the inter-event patchset.  This restores
      it.
      
      Below are a couple examples - in the first case, .usecs wasn't being
      displayed properly for common_timestamps and the second illustrates
      the same for other flags such as .execname.
      
      Before:
      
        # echo 'hist:key=common_pid.execname:val=count:sort=count' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
        # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
        hist:keys=common_pid:vals=hitcount,count:sort=count:size=2048 [active]
      
        # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
        # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
        hist:keys=pid:vals=hitcount:ts0=common_timestamp:sort=hitcount:size=2048:clock=global if comm=="cyclictest" [active]
      
      After:
      
        # echo 'hist:key=common_pid.execname:val=count:sort=count' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
        # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
        hist:keys=common_pid.execname:vals=hitcount,count:sort=count:size=2048 [active]
      
        # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
        # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
        hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global if comm=="cyclictest" [active]
      
      Link: http://lkml.kernel.org/r/492bab42ff21806600af98a8ea901af10efbee0c.1524790601.git.tom.zanussi@linux.intel.comSigned-off-by: NTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      608940da
  12. 06 4月, 2018 5 次提交
  13. 23 3月, 2018 1 次提交
  14. 11 3月, 2018 20 次提交