'success' is left here for a long time and also it is meaningless
for the upper user. Just remove it.
Signed-off-by: Ed Tsai <[email protected]>
---
include/trace/events/sched.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index cbe3e152d24c..720204539e0b 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -148,7 +148,6 @@ DECLARE_EVENT_CLASS(sched_wakeup_template,
__array( char, comm, TASK_COMM_LEN )
__field( pid_t, pid )
__field( int, prio )
- __field( int, success )
__field( int, target_cpu )
),
@@ -156,7 +155,6 @@ DECLARE_EVENT_CLASS(sched_wakeup_template,
memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid = p->pid;
__entry->prio = p->prio; /* XXX SCHED_DEADLINE */
- __entry->success = 1; /* rudiment, kill when possible */
__entry->target_cpu = task_cpu(p);
),
--
2.18.0
On Thu, 22 Apr 2021 20:22:26 +0800
Ed Tsai <[email protected]> wrote:
> 'success' is left here for a long time and also it is meaningless
> for the upper user. Just remove it.
Have you tested all userspace code that might use this?
This is the "poster boy" example of why Peter Zijlstra hates trace events ;-)
I know I've updated trace-cmd to check to see if this field exits before
depending on it, but there may be some other tools that may not. Perhaps
nothing will break.
I'm all for this change, but be ware, it might be reverted if there's some
tool out that that expects it to exist. This is why it hasn't been removed.
-- Steve
On Thu, 2021-04-22 at 11:46 -0400, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 20:22:26 +0800
> Ed Tsai <[email protected]> wrote:
>
> > 'success' is left here for a long time and also it is meaningless
> > for the upper user. Just remove it.
>
> Have you tested all userspace code that might use this?
>
> This is the "poster boy" example of why Peter Zijlstra hates trace
> events ;-)
>
> I know I've updated trace-cmd to check to see if this field exits
> before
> depending on it, but there may be some other tools that may not.
> Perhaps
> nothing will break.
>
> I'm all for this change, but be ware, it might be reverted if there's
> some
> tool out that that expects it to exist. This is why it hasn't been
> removed.
>
> -- Steve
It is left here over 5 years. Old userspace code need this entry and
also someone may use it for a new tool. I hate this but it is a problem
should be resolved for the kernel or ignore just fine.
On Fri, 23 Apr 2021 08:38:22 +0800
Ed Tsai <[email protected]> wrote:
> On Thu, 2021-04-22 at 11:46 -0400, Steven Rostedt wrote:
> > On Thu, 22 Apr 2021 20:22:26 +0800
> > Ed Tsai <[email protected]> wrote:
> >
> > > 'success' is left here for a long time and also it is meaningless
> > > for the upper user. Just remove it.
> >
> > Have you tested all userspace code that might use this?
> >
> > This is the "poster boy" example of why Peter Zijlstra hates trace
> > events ;-)
> >
> > I know I've updated trace-cmd to check to see if this field exits
> > before
> > depending on it, but there may be some other tools that may not.
> > Perhaps
> > nothing will break.
> >
> > I'm all for this change, but be ware, it might be reverted if there's
> > some
> > tool out that that expects it to exist. This is why it hasn't been
> > removed.
> >
> > -- Steve
>
> It is left here over 5 years. Old userspace code need this entry and
> also someone may use it for a new tool. I hate this but it is a problem
> should be resolved for the kernel or ignore just fine.
>
I'm willing to take this, with a note that if anyone complains, it may
be reverted. But as it goes with Linus's rule about breaking user
space. If you break user space, and nobody notices, you didn't really
break it!
-- Steve
On Sun, 2021-04-25 at 17:54 -0400, Steven Rostedt wrote:
> On Fri, 23 Apr 2021 08:38:22 +0800
> Ed Tsai <[email protected]> wrote:
>
> > On Thu, 2021-04-22 at 11:46 -0400, Steven Rostedt wrote:
> > > On Thu, 22 Apr 2021 20:22:26 +0800
> > > Ed Tsai <[email protected]> wrote:
> > >
> > > > 'success' is left here for a long time and also it is
> > > > meaningless
> > > > for the upper user. Just remove it.
> > >
> > > Have you tested all userspace code that might use this?
> > >
> > > This is the "poster boy" example of why Peter Zijlstra hates
> > > trace
> > > events ;-)
> > >
> > > I know I've updated trace-cmd to check to see if this field exits
> > > before
> > > depending on it, but there may be some other tools that may not.
> > > Perhaps
> > > nothing will break.
> > >
> > > I'm all for this change, but be ware, it might be reverted if
> > > there's
> > > some
> > > tool out that that expects it to exist. This is why it hasn't
> > > been
> > > removed.
> > >
> > > -- Steve
> >
> > It is left here over 5 years. Old userspace code need this entry
> > and
> > also someone may use it for a new tool. I hate this but it is a
> > problem
> > should be resolved for the kernel or ignore just fine.
> >
>
> I'm willing to take this, with a note that if anyone complains, it
> may
> be reverted. But as it goes with Linus's rule about breaking user
> space. If you break user space, and nobody notices, you didn't really
> break it!
>
> -- Steve
>
>
Thx Steve, this change work fine to me on the trace-cmd and systrace.
It's a simple patch to clean code. Revert it if break user experience.
On Sun, Apr 25, 2021 at 05:54:26PM -0400, Steven Rostedt wrote:
> On Fri, 23 Apr 2021 08:38:22 +0800
> Ed Tsai <[email protected]> wrote:
>
> > On Thu, 2021-04-22 at 11:46 -0400, Steven Rostedt wrote:
> > > On Thu, 22 Apr 2021 20:22:26 +0800
> > > Ed Tsai <[email protected]> wrote:
> > >
> > > > 'success' is left here for a long time and also it is meaningless
> > > > for the upper user. Just remove it.
> > >
> > > Have you tested all userspace code that might use this?
> > >
> > > This is the "poster boy" example of why Peter Zijlstra hates trace
> > > events ;-)
> > >
> > > I know I've updated trace-cmd to check to see if this field exits
> > > before
> > > depending on it, but there may be some other tools that may not.
> > > Perhaps
> > > nothing will break.
> > >
> > > I'm all for this change, but be ware, it might be reverted if there's
> > > some
> > > tool out that that expects it to exist. This is why it hasn't been
> > > removed.
> > >
> > > -- Steve
> >
> > It is left here over 5 years. Old userspace code need this entry and
> > also someone may use it for a new tool. I hate this but it is a problem
> > should be resolved for the kernel or ignore just fine.
> >
>
> I'm willing to take this, with a note that if anyone complains, it may
> be reverted. But as it goes with Linus's rule about breaking user
> space. If you break user space, and nobody notices, you didn't really
> break it!
LatencyTop was I think the offender at the time, but I can't really
remember. Anyway, glad to be rid of it, if we get away with it that is
;-)
On Mon, 26 Apr 2021 14:18:31 +0800
Ed Tsai <[email protected]> wrote:
> Thx Steve, this change work fine to me on the trace-cmd and systrace.
> It's a simple patch to clean code. Revert it if break user experience.
I'll take it for the next merge window. I don't want to introduce a
possible regression during the current merge window.
-- Steve