Re: [PATCH] ftrace, sched: Add TRACE_FLAG_PREEMPT_RESCHED

[Peter Zijlstra]

On Fri, Oct 04, 2013 at 10:53:42AM -0400, Steven Rostedt wrote:
> On Fri, 4 Oct 2013 10:09:09 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
> > On Fri, Sep 27, 2013 at 05:29:08PM +0200, Peter Zijlstra wrote:
> > > Subject: ftrace, sched: Add TRACE_FLAG_PREEMPT_RESCHED
> > > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > > Date: Fri Sep 27 17:11:00 CEST 2013
> > > 
> > > Since we now have two need_resched states; trace the two so we can
> > > observe discrepancies.
> > > 
> > > Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
> > > Signed-off-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > 
> > Steve, if you're done conferencing.. any objections?
> > 
> 
> Taking a quick look, my only objection so far is that the change log is
> rather flimsy. What are the two states and what are their dependencies?
> 
> In other words, what does these flags in the trace actually mean?
> Probably need to add comments in the code and/or update the
> Documentation section

Ah, you missed the preemption series?

1a338ac32ca6 sched, x86: Optimize the preempt_schedule() call
c2daa3bed53a sched, x86: Provide a per-cpu preempt_count implementation
a233f1120c37 sched: Prepare for per-cpu preempt_count
bdb438065890 sched: Extract the basic add/sub preempt_count modifiers
01028747559a sched: Create more preempt_count accessors
a787870924db sched, arch: Create asm/preempt.h
f27dde8deef3 sched: Add NEED_RESCHED to the preempt_count
4a2b4b222743 sched: Introduce preempt_count accessor functions
ea8117478918 sched, idle: Fix the idle polling state logic
315039862646 sched: Remove {set,clear}_need_resched
b021fe3e2509 sched, rcu: Make RCU use resched_cpu()
0c44c2d0f459 x86: Use asm goto to implement better modify_and_test() functions

preempt_count now includes a NEED_RESCHED and this patch shows which
is set: N both PREEMPT_NEED_RESCHED and TIF_NEED_RESCHED, n for TIF only
and p for preempt only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/