<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/include/trace/events/sched.h, branch linux-3.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2013-11-06T06:50:37Z</updated>
<entry>
<title>Merge branch 'sched/core' into core/locking, to prepare the kernel/locking/ file move</title>
<updated>2013-11-06T06:50:37Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2013-11-06T06:50:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c90423d1de12fbeaf0c898e1db0e962de347302b'/>
<id>urn:sha1:c90423d1de12fbeaf0c898e1db0e962de347302b</id>
<content type='text'>
Conflicts:
	kernel/Makefile

There are conflicts in kernel/Makefile due to file moving in the
scheduler tree - resolve them.

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>hung_task debugging: Add tracepoint to report the hang</title>
<updated>2013-10-31T10:16:18Z</updated>
<author>
<name>Oleg Nesterov</name>
</author>
<published>2013-10-19T16:18:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6a716c90a51338009c3bc1f460829afaed8f922d'/>
<id>urn:sha1:6a716c90a51338009c3bc1f460829afaed8f922d</id>
<content type='text'>
Currently check_hung_task() prints a warning if it detects the
problem, but it is not convenient to watch the system logs if
user-space wants to be notified about the hang.

Add the new trace_sched_process_hang() into check_hung_task(),
this way a user-space monitor can easily wait for the hang and
potentially resolve a problem.

Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Dave Sullivan &lt;dsulliva@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Link: http://lkml.kernel.org/r/20131019161828.GA7439@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>sched: Create more preempt_count accessors</title>
<updated>2013-09-25T12:07:52Z</updated>
<author>
<name>Peter Zijlstra</name>
</author>
<published>2013-08-14T12:55:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=01028747559ac6c6f642a7bbd2875cc4f66b2feb'/>
<id>urn:sha1:01028747559ac6c6f642a7bbd2875cc4f66b2feb</id>
<content type='text'>
We need a few special preempt_count accessors:
 - task_preempt_count() for when we're interested in the preemption
   count of another (non-running) task.
 - init_task_preempt_count() for properly initializing the preemption
   count.
 - init_idle_preempt_count() a special case of the above for the idle
   threads.

With these no generic code ever touches thread_info::preempt_count
anymore and architectures could choose to remove it.

Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: http://lkml.kernel.org/n/tip-jf5swrio8l78j37d06fzmo4r@git.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>tracing/perf: Reimplement TP_perf_assign() logic</title>
<updated>2013-08-14T01:05:57Z</updated>
<author>
<name>Oleg Nesterov</name>
</author>
<published>2013-08-06T16:08:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=12473965c38a527a0c6f7a38d23edce60957f873'/>
<id>urn:sha1:12473965c38a527a0c6f7a38d23edce60957f873</id>
<content type='text'>
The next patch tries to avoid the costly perf_trace_buf_* calls
when possible but there is a problem. We can only do this if
__task == NULL, perf_tp_event(task != NULL) has the additional
code for this case.

Unfortunately, TP_perf_assign/__perf_xxx which changes the default
values of __count/__task variables for perf_trace_buf_submit() is
called "too late", after we already did perf_trace_buf_prepare(),
and the optimization above can't work.

So this patch simply embeds __perf_xxx() into TP_ARGS(), this way
DECLARE_EVENT_CLASS() can use the result of assignments hidden in
"args" right after ftrace_get_offsets_##call() which is mostly
trivial. This allows us to have the fast-path "__task != NULL"
check at the start, see the next patch.

Link: http://lkml.kernel.org/r/20130806160844.GA2739@redhat.com

Tested-by: David Ahern &lt;dsahern@gmail.com&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing/perf: Expand TRACE_EVENT(sched_stat_runtime)</title>
<updated>2013-08-14T01:05:12Z</updated>
<author>
<name>Oleg Nesterov</name>
</author>
<published>2013-08-06T16:08:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=36009d07b79d2a168d6037947357d96e5d8cebe7'/>
<id>urn:sha1:36009d07b79d2a168d6037947357d96e5d8cebe7</id>
<content type='text'>
To simplify the review of the next patches:

1. We are going to reimplent __perf_task/counter and embedd them
   into TP_ARGS(). expand TRACE_EVENT(sched_stat_runtime) into
   DECLARE_EVENT_CLASS() + DEFINE_EVENT(), this way they can use
   different TP_ARGS's.

2. Change perf_trace_##call() macro to do perf_fetch_caller_regs()
   right before perf_trace_buf_prepare().

   This way it evaluates TP_ARGS() asap, the next patch explores
   this fact.

   Note: after 87f44bbc perf_trace_buf_prepare() doesn't need
   "struct pt_regs *regs", perhaps it makes sense to remove this
   argument. And perhaps we can teach perf_trace_buf_submit()
   to accept regs == NULL and do fetch_caller_regs(CALLER_ADDR1)
   in this case.

3. Cosmetic, but the typecast from "void*" buys nothing. It just
   adds the noise, remove it.

Link: http://lkml.kernel.org/r/20130806160841.GA2736@redhat.com

Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Tested-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>kthread: Prevent unpark race which puts threads on the wrong cpu</title>
<updated>2013-04-12T12:18:43Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2013-04-09T07:33:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f2530dc71cf0822f90bb63ea4600caaef33a66bb'/>
<id>urn:sha1:f2530dc71cf0822f90bb63ea4600caaef33a66bb</id>
<content type='text'>
The smpboot threads rely on the park/unpark mechanism which binds per
cpu threads on a particular core. Though the functionality is racy:

CPU0	       	 	CPU1  	     	    CPU2
unpark(T)				    wake_up_process(T)
  clear(SHOULD_PARK)	T runs
			leave parkme() due to !SHOULD_PARK  
  bind_to(CPU2)		BUG_ON(wrong CPU)						    

We cannot let the tasks move themself to the target CPU as one of
those tasks is actually the migration thread itself, which requires
that it starts running on the target cpu right away.

The solution to this problem is to prevent wakeups in park mode which
are not from unpark(). That way we can guarantee that the association
of the task to the target cpu is working correctly.

Add a new task state (TASK_PARKED) which prevents other wakeups and
use this state explicitly for the unpark wakeup.

Peter noticed: Also, since the task state is visible to userspace and
all the parked tasks are still in the PID space, its a good hint in ps
and friends that these tasks aren't really there for the moment.

The migration thread has another related issue.

CPU0	      	     	 CPU1
Bring up CPU2
create_thread(T)
park(T)
 wait_for_completion()
			 parkme()
			 complete()
sched_set_stop_task()
			 schedule(TASK_PARKED)

The sched_set_stop_task() call is issued while the task is on the
runqueue of CPU1 and that confuses the hell out of the stop_task class
on that cpu. So we need the same synchronizaion before
sched_set_stop_task().

Reported-by: Dave Jones &lt;davej@redhat.com&gt;
Reported-and-tested-by: Dave Hansen &lt;dave@sr71.net&gt;
Reported-and-tested-by: Borislav Petkov &lt;bp@alien8.de&gt;
Acked-by: Peter Ziljstra &lt;peterz@infradead.org&gt;
Cc: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Cc: dhillf@gmail.com
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304091635430.21884@ionos
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;

</content>
</entry>
<entry>
<title>perf/trace: Add ability to set a target task for events</title>
<updated>2012-07-31T15:02:05Z</updated>
<author>
<name>Andrew Vagin</name>
</author>
<published>2012-07-11T14:14:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e6dab5ffab59e910ec0e3355f4a6f29f7a7be474'/>
<id>urn:sha1:e6dab5ffab59e910ec0e3355f4a6f29f7a7be474</id>
<content type='text'>
A few events are interesting not only for a current task.
For example, sched_stat_* events are interesting for a task
which wakes up. For this reason, it will be good if such
events will be delivered to a target task too.

Now a target task can be set by using __perf_task().

The original idea and a draft patch belongs to Peter Zijlstra.

I need these events for profiling sleep times. sched_switch is used for
getting callchains and sched_stat_* is used for getting time periods.
These events are combined in user space, then it can be analyzed by
perf tools.

Inspired-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Arnaldo Carvalho de Melo &lt;acme@ghostprotocols.net&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Arun Sharma &lt;asharma@fb.com&gt;
Signed-off-by: Andrew Vagin &lt;avagin@openvz.org&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Link: http://lkml.kernel.org/r/1342016098-213063-1-git-send-email-avagin@openvz.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>tracing, sched, vfs: Fix 'old_pid' usage in trace_sched_process_exec()</title>
<updated>2012-03-31T09:53:22Z</updated>
<author>
<name>Oleg Nesterov</name>
</author>
<published>2012-03-30T16:26:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6308191f6f55d3629c7dbe72dfb856ad9fa560fd'/>
<id>urn:sha1:6308191f6f55d3629c7dbe72dfb856ad9fa560fd</id>
<content type='text'>
1. TRACE_EVENT(sched_process_exec) forgets to actually use the
   old pid argument, it sets -&gt;old_pid = p-&gt;pid.

2. search_binary_handler() uses the wrong pid number. tracepoint
   needs the global pid_t from the root namespace, while old_pid
   is the virtual pid number as it seen by the tracer/parent.

With this patch we have two pid_t's in search_binary_handler(),
not really nice. Perhaps we should switch to "struct pid*", but
in this case it would be better to cleanup the current code
first and move the "depth == 0" code outside.

Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: David Smith &lt;dsmith@redhat.com&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Link: http://lkml.kernel.org/r/20120330162636.GA4857@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'perf/urgent' into perf/core</title>
<updated>2012-03-05T08:20:08Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2012-03-05T08:20:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=737f24bda723fdf89ecaacb99fa2bf5683c32799'/>
<id>urn:sha1:737f24bda723fdf89ecaacb99fa2bf5683c32799</id>
<content type='text'>
Conflicts:
	tools/perf/builtin-record.c
	tools/perf/builtin-top.c
	tools/perf/perf.h
	tools/perf/util/top.h

Merge reason: resolve these cherry-picking conflicts.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>tracepoint, vfs, sched: Add exec() tracepoint</title>
<updated>2012-02-23T08:28:06Z</updated>
<author>
<name>David Smith</name>
</author>
<published>2012-02-07T16:11:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4ff16c25e2cc48cbe6956e356c38a25ac063a64d'/>
<id>urn:sha1:4ff16c25e2cc48cbe6956e356c38a25ac063a64d</id>
<content type='text'>
Added a minimal exec tracepoint. Exec is an important major event
in the life of a task, like fork(), clone() or exit(), all of
which we already trace.

[ We also do scheduling re-balancing during exec() - so it's useful
  from a scheduler instrumentation POV as well. ]

If you want to watch a task start up, when it gets exec'ed is a good place
to start.  With the addition of this tracepoint, exec's can be monitored
and better picture of general system activity can be obtained. This
tracepoint will also enable better process life tracking, allowing you to
answer questions like "what process keeps starting up binary X?".

This tracepoint can also be useful in ftrace filtering and trigger
conditions: i.e. starting or stopping filtering when exec is called.

Signed-off-by: David Smith &lt;dsmith@redhat.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/4F314D19.7030504@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
</feed>
