Linux Hotplug development
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	amit.kucheria@linaro.org, Rusty Russell <rusty@rustcorp.com.au>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
Date: Wed, 02 Mar 2011 10:08:45 +0000	[thread overview]
Message-ID: <alpine.LFD.2.00.1103021056460.2701@localhost6.localdomain6> (raw)
In-Reply-To: <AANLkTik1Aqt8qJ62h4k0PbLOU7qu3TtA=fWn=LJ6tQjc@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2796 bytes --]

Vincent,

On Mon, 28 Feb 2011, Vincent Guittot wrote:
> On 24 February 2011 19:40, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Thu, 24 Feb 2011, Vincent Guittot wrote:

Sorry, this mail got eaten somehow, but I got it from my archive.

> >>  #ifdef CONFIG_SMP
> >>  /* Serializes the updates to cpu_online_mask, cpu_present_mask */
> >>  static DEFINE_MUTEX(cpu_add_remove_lock);
> >> @@ -197,10 +200,13 @@ struct take_cpu_down_param {
> >>  static int __ref take_cpu_down(void *_param)
> >>  {
> >>       struct take_cpu_down_param *param = _param;
> >> +     unsigned int cpu = (unsigned int)(param->hcpu);
> >>       int err;
> >>
> >>       /* Ensure this CPU doesn't handle any more interrupts. */
> >> +     trace_cpu_hotplug_disable_start(cpu);
> >>       err = __cpu_disable();
> >> +     trace_cpu_hotplug_disable_end(cpu);
> >
> > How useful. What about recording the return code of __cpu_disable()?
> >
> 
> The goal is to monitor the cpu hotplug activity and duration. I want
> to detect 2 kind of cpu_down/cpu_up call, ones which succeed to
> unplug/plug a core and ones which don't. But I'm not sure that we need
> to sort the failed calls into to the trace. We trace them because too
> much fails could point out a bug or a wrong use of cpu hotplug.

This does not make sense at all. You want to see the failures, then
recording the error code makes even more sense. Your way of decoding
the error case by checking whether the next trace entry is there or
missing is just sloppy.
 
> >>       if (err < 0)
> >>               return err;
> >
> >> +     trace_cpu_hotplug_down_start(cpu);
> >> +
> >
> > What's the point of this tracepoint _BEFORE_ the cpu_hotplug_disabled
> > check without recording cpu_hotplug_disabled ?
> >
> 
> I want to trace all cpu_down call even those which returns immediately
> which will be part of the failed calls.

Decoding failure from missing entries is simply wrong.
 
> >>       if (cpu_hotplug_disabled) {
> >>               err = -EBUSY;
> >>               goto out;
> >> @@ -284,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
> >>       err = _cpu_down(cpu, 0);
> >>
> >>  out:
> >> +     trace_cpu_hotplug_down_end(cpu);
> >
> > And this one is misplaced as well. It wants to be only called when we
> > actually called _cpu_down() and it wants to record the return code as
> > well.
> >
> 
> It has been placed here to be called each time
> trace_cpu_hotplug_down_start is called.

That does not make sense at all. You cannot distinguish between
cpu_hotplug_disabled set and the _cpu_down() being called case. Or do
you want to tell me that you decode that from the time stamps? Hell
no. We want traces which are readable w/o crystal balls.
 
Thanks,

	tglx

  reply	other threads:[~2011-03-02 10:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24 17:33 [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events Vincent Guittot
2011-02-24 18:40 ` Thomas Gleixner
2011-02-28 13:36   ` Vincent Guittot
2011-03-02 10:08     ` Thomas Gleixner [this message]
2011-03-02 19:02       ` Vincent Guittot
2011-03-02 21:12         ` Thomas Gleixner
2011-02-24 18:46 ` Peter Zijlstra
2011-02-24 20:11   ` Alan Cox
2011-02-24 20:16     ` Thomas Gleixner
2011-02-24 20:24       ` Nicolas Pitre
2011-02-24 20:30         ` Peter Zijlstra
2011-02-24 20:40           ` Alan Cox
2011-02-24 20:40           ` Nicolas Pitre
2011-02-24 20:49             ` Peter Zijlstra
2011-02-24 20:49             ` Thomas Gleixner
2011-02-24 21:04               ` Alan Cox
2011-02-24 21:12                 ` Thomas Gleixner
2011-02-24 21:17                   ` Peter Zijlstra
2011-02-24 21:33                     ` Thomas Gleixner
2011-02-24 20:47           ` Thomas Gleixner
2011-02-24 20:58             ` Peter Zijlstra
2011-02-24 21:03               ` Thomas Gleixner
2011-02-24 21:11               ` Paul E. McKenney
2011-02-24 20:27     ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1103021056460.2701@localhost6.localdomain6 \
    --to=tglx@linutronix.de \
    --cc=amit.kucheria@linaro.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox