On Wed, 2012-05-16 at 15:32 -0400, Steven Rostedt wrote:
> On Wed, 2012-05-16 at 19:48 +0200, Jiri Olsa wrote:
>
> > for ppc64(record) vs x86_64(report) I got following report on latest tip:
> >
> > [jolsa@dhcp-26-214 test]$ ../perf report > report.target
> > End
On Wed, 2012-05-16 at 15:08 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 16, 2012 at 12:58:23PM -0400, Steven Rostedt escreveu:
> > On Wed, 2012-05-16 at 11:59 -0300, Arnaldo Carvalho de Melo wrote:
> > > Was the kernel trace events infrastructure designed with that
On Wed, 2012-05-16 at 11:59 -0300, Arnaldo Carvalho de Melo wrote:
> Steve,
>
> Was the kernel trace events infrastructure designed with that in
> mind? I.e. cross analysis? I must be missing something here, still
> ENOCOFFEE :-\
Yes, the libparsevents library was design for this from day
On Thu, 2012-05-17 at 09:10 +0400, Dmitry Antipov wrote:
> On 05/16/2012 08:58 PM, Steven Rostedt wrote:
>
> > On Wed, 2012-05-16 at 11:59 -0300, Arnaldo Carvalho de Melo wrote:
> >
> >> Steve,
> >>
> >>Was the kernel trace events infrastructur
On Wed, 2012-05-16 at 19:48 +0200, Jiri Olsa wrote:
> for ppc64(record) vs x86_64(report) I got following report on latest tip:
>
> [jolsa@dhcp-26-214 test]$ ../perf report > report.target
> Endianness of raw data not corrected!
> Warning:
> 718 samples with id not present in the header
> Warning
On Tue, 2012-10-23 at 18:30 +0100, Pawel Moll wrote:
>
> === Option 1: Trace event ===
>
> This seems to be the "cheapest" option. Simply defining a trace event
> that can be generated by a hwmon (or any other) driver makes the
> interesting data immediately available to any ftrace/perf user. Of
On Mon, 2012-11-26 at 20:30 +0530, Viresh Kumar wrote:
> On 6 November 2012 16:08, Viresh Kumar wrote:
> > This is V2 Resend of my sched_select_cpu() work. Resend because didn't got
> > much
> > attention on V2. Including more guys now in cc :)
> >
> > In order to save power, it would be useful t
On Mon, 2012-11-26 at 09:03 -0800, Paul E. McKenney wrote:
> If I understand correctly (though also suffering turkey OD), the idea is
> to offload work to more energy-efficient CPUs.
This is determined by a CPU that isn't running the idle task? Is it
because a CPU that just woke up may be runnin
On Mon, 2012-11-26 at 11:03 -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2012 at 12:35:52PM -0500, Steven Rostedt wrote:
> > On Mon, 2012-11-26 at 09:03 -0800, Paul E. McKenney wrote:
> >
> >
> > > If I understand correctly (though also suffering turkey OD), the
On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
> Workqueues queues work on current cpu, if the caller haven't passed a
> preferred
> cpu. This may wake up an idle CPU, which is actually not required.
>
> This work can be processed by any CPU and so we must select a non-idle CPU
> here.
>
[ Added John Stultz ]
On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
> Till now, we weren't migrating a running timer because with migration
> del_timer_sync() can't detect that the timer's handler yet has not finished.
>
> Now, when can we actually to reach to the code (inside __mod_time
On Tue, 2012-11-27 at 15:55 +0100, Vincent Guittot wrote:
> On 27 November 2012 14:59, Steven Rostedt wrote:
> > On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
> >> On 27 November 2012 18:56, Steven Rostedt wrote:
> >> > A couple of things. The sched_selec
On Tue, 2012-11-27 at 19:18 +0530, Viresh Kumar wrote:
> On 27 November 2012 18:56, Steven Rostedt wrote:
> > A couple of things. The sched_select_cpu() is not cheap. It has a double
> > loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
> > and we are C
On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
> > By default, I would suggest for cache locality,
> > that we try to keep it on the same CPU. But if there's a better CPU to
> > run on, it runs there.
>
> That would break our intention behind this routine. We should run
> it on a cpu whic
On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
> Hi Tejun,
>
> On 4 January 2013 20:39, Tejun Heo wrote:
> > I don't know either. Changing behavior subtly like this is hard. I
> > usually try to spot some problem cases and try to identify patterns
> > there. Once you identify a few of
On Fri, 2013-02-08 at 12:11 +0100, Vincent Guittot wrote:
> When a RT task is scheduled on an idle CPU, the update of the rq's load is
> not done because CFS's functions are not called. Then, the idle_balance,
> which is called just before entering the idle function, updates the
> rq's load and mak
On Tue, 2013-02-12 at 14:23 +0100, Vincent Guittot wrote:
> .set_curr_task = set_curr_task_idle,
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index fc88644..9707092 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -877,6 +877,7 @@ extern const str
17 matches
Mail list logo
