* Steven Rostedt wrote:
> On Tue, 23 Feb 2016 11:44:08 +0100
> Peter Zijlstra wrote:
>
> > No it very much illustrates the problem and is a very clear indication
> > that tracepoints are an ABI.
>
> Yes they are. But note, they can change if nobody notices ;-)
Which is rather seldom for some
On 02/23/2016 07:44 AM, Peter Zijlstra wrote:
> Now ideally we'd do something like the below, but because trainwreck, we
> cannot actually do this I think :-(
Some other considerations:
1) The majority of tasks run on NORMAL scheduler with default nice. So,
prev=NORMAL:{0,0,0} and next=NORMAL:{
On 02/23/2016 07:44 AM, Peter Zijlstra wrote:
>>> Worse, the proposed tracepoints are atrocious, look at crap like this:
>>> > >
> > > +if (trace_sched_deadline_yield_enabled()) {
> > > +u64 delta_exec = rq_clock_task(rq) -
> > > p->se.exec_start;
On Tue, Feb 23, 2016 at 11:44:08AM +0100, Peter Zijlstra wrote:
> include/trace/events/sched.h | 97
> +++-
> 1 file changed, 86 insertions(+), 11 deletions(-)
>
> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> index 9b90c57517a
On Tue, 23 Feb 2016 11:44:08 +0100
Peter Zijlstra wrote:
> No it very much illustrates the problem and is a very clear indication
> that tracepoints are an ABI.
Yes they are. But note, they can change if nobody notices ;-)
> >
> > Heh, it's not really changing state. The code directly after t
On Mon, Feb 22, 2016 at 05:30:43PM -0500, Steven Rostedt wrote:
> On Mon, 22 Feb 2016 22:30:17 +0100
> Peter Zijlstra wrote:
>
> > On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote:
> >
> > > > As it stands, the existing tracepoint have already been an ABI
> > > > trainwreck, why wo
Hi,
On 22/02/16 17:30, Steven Rostedt wrote:
> On Mon, 22 Feb 2016 22:30:17 +0100
> Peter Zijlstra wrote:
>
> > On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote:
> >
[...]
> >
> > > But let me ask, what would you recommend to finding out if the kernel
> > > has really given you
On Mon, 22 Feb 2016 22:30:17 +0100
Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote:
>
> > > As it stands, the existing tracepoint have already been an ABI
> > > trainwreck, why would I want to add more?
> >
> > Yes, this may become a type of ABI, but eve
On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote:
> > As it stands, the existing tracepoint have already been an ABI
> > trainwreck, why would I want to add more?
>
> Yes, this may become a type of ABI, but even the sched switch
> tracepoints haven't been that bad. Has it really pre
On 02/22/2016 02:48 PM, Steven Rostedt wrote:
> On Mon, 22 Feb 2016 18:32:59 +0100
> Peter Zijlstra wrote:
>
>
>> > So I'm a bit allergic to tracepoints and this is very flimsy on reasons
>> > why I would want to do this.
> Because there's no way to know if SCHED_DEADLINE tasks are doing what
On Mon, 22 Feb 2016 18:32:59 +0100
Peter Zijlstra wrote:
> So I'm a bit allergic to tracepoints and this is very flimsy on reasons
> why I would want to do this.
Because there's no way to know if SCHED_DEADLINE tasks are doing what
they suppose to without hacking the kernel and adding your own
Hi Daniel,
[auto build test WARNING on tip/sched/core]
[also build test WARNING on v4.5-rc5 next-20160222]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Bristot-de-Oliveira/Tracepoints
On Mon, Feb 22, 2016 at 02:08:21PM -0300, Daniel Bristot de Oliveira wrote:
> Deadline tasks behave differently of other tasks because deadline
> task's also depend on their period, deadline and runtime.
>
> Hence, the well known sched:sched_wakeup and sched:sched_switch
> tracepoints are not alwa
Deadline tasks behave differently of other tasks because deadline
task's also depend on their period, deadline and runtime.
Hence, the well known sched:sched_wakeup and sched:sched_switch
tracepoints are not always enough to precisely explain the behavior of a
deadline task with respect to the tas
14 matches
Mail list logo
