Neil Brown | 1 Jun 01:00 2010
Picon

Re: [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010 00:05:19 +0200
"Rafael J. Wysocki" <rjw <at> sisk.pl> wrote:

> On Monday 31 May 2010, Neil Brown wrote:
> > On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> > Thomas Gleixner <tglx <at> linutronix.de> wrote:
> > 
> > > On Thu, 27 May 2010, Rafael J. Wysocki wrote:
> > > 
> > > > On Thursday 27 May 2010, Thomas Gleixner wrote:
> > > > > On Thu, 27 May 2010, Alan Stern wrote:
> > > > > 
> > > > > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > > > > 
> > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > > > > >If people don't mind, here is a greatly simplified summary of the
> > > > > > > >comments and objections I have seen so far on this thread:
> > > > > > > >
> > > > > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > > > > >	beneficial.
> > > > > > > 
> > > > > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > > > > the kernel decide which power state is better as long as I can say I 
> > > > > > > need 100us IRQ latency or 100ms wakeup latency.
> > > > > > 
> > > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > > > 
> > > > > mem should be replaced by an idle suspend to ram mechanism
> > > > 
(Continue reading)

Frederic Weisbecker | 1 Jun 01:02 2010
Picon

[GIT PULL] perf fixes

Ingo,

Please pull the perf/urgent branch that can be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	perf/urgent

Thanks,
	Frederic
---

Frederic Weisbecker (3):
      perf: Process comm events by tid
      perf: Use event__process_task from perf sched
      perf: Do the comm inheritance per thread in event__process_task

Borislav Petkov (1):
      perf-record: Check correct pid when forking

 tools/perf/builtin-record.c |    3 +--
 tools/perf/builtin-sched.c  |    1 +
 tools/perf/util/event.c     |   13 ++++---------
 3 files changed, 6 insertions(+), 11 deletions(-)
Frederic Weisbecker | 1 Jun 01:02 2010
Picon

[PATCH 2/4] perf: Use event__process_task from perf sched

perf sched uses event__process_comm(), which means it can resolve
comms from:

- tasks that have exec'ed (kernel comm events)
- tasks that were running when perf record started the actual
  recording (synthetized comm events)

But perf sched can't resolve the pids of tasks that were created
after the recording started.

To solve this, we need to inherit the comms on fork events using
event__process_task().

This fixes various unresolved pids in perf sched, easily visible
with:
	perf sched record perf bench sched messaging

Signed-off-by: Frederic Weisbecker <fweisbec <at> gmail.com>
Cc: Ingo Molnar <mingo <at> elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
Cc: Arnaldo Carvalho de Melo <acme <at> redhat.com>
Cc: Paul Mackerras <paulus <at> samba.org>
Cc: Tom Zanussi <tzanussi <at> gmail.com>
Cc: Stephane Eranian <eranian <at> google.com>
---
 tools/perf/builtin-sched.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index f67bce2..55f3b5d 100644
(Continue reading)

Frederic Weisbecker | 1 Jun 01:02 2010
Picon

[PATCH 3/4] perf: Do the comm inheritance per thread in event__process_task

event__process_task() doesn't propagate the comm copy on clone,
but only on process fork. So we loose all the tid:comm resolution
for tasks that aren't a main process thread.

Progragate the per thread granularity to event__process_task for
pid resolution.

This fixes various unresolved pids in perf sched, especially when
we trace multithread processes. The problem is quickly reproducible
with the messaging benchmark using the multithread mode "-t" :

	perf sched record perf bench sched messaging -t

Signed-off-by: Frederic Weisbecker <fweisbec <at> gmail.com>
Cc: Ingo Molnar <mingo <at> elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
Cc: Arnaldo Carvalho de Melo <acme <at> redhat.com>
Cc: Paul Mackerras <paulus <at> samba.org>
Cc: Tom Zanussi <tzanussi <at> gmail.com>
Cc: Stephane Eranian <eranian <at> google.com>
---
 tools/perf/util/event.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index d28d809..1f08f00 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
 <at>  <at>  -532,16 +532,11  <at>  <at>  out_problem:

(Continue reading)

Frederic Weisbecker | 1 Jun 01:02 2010
Picon

[PATCH 1/4] perf: Process comm events by tid

When we synthetize the existing running tasks though procfs,
we walk through every threads of a process, queuing one comm
events per tid.

But then on report time, event__process_comm() only creates and
sets the comm on a per process granularity. This is the right
thing for comm events that came from the kernel, as they are
only created on exec. Sub-threads then inherit their comm
from fork events. But that doesn't work with our synthetized
comm events taken from procfs informations as the per thread
granularity is done on comm events directly there.

Hence we need event__process_comm() to work with the tid rather
than the pid. It won't change anything for comm events coming
from the kernel but this will fix the synthetized ones.

Before:

	$ ./perf report -D | grep COMM | grep firefox

	0x2c7b8 [0x18]: PERF_RECORD_COMM: firefox:5297
	0x2c7d0 [0x18]: PERF_RECORD_COMM: firefox:5297
	0x2c7e8 [0x18]: PERF_RECORD_COMM: firefox:5297
	0x2c800 [0x18]: PERF_RECORD_COMM: firefox:5297
	0x2c818 [0x18]: PERF_RECORD_COMM: firefox:5297
	0x2c830 [0x18]: PERF_RECORD_COMM: firefox:5297

After:
	$ ./perf report -D | grep COMM | grep firefox

(Continue reading)

Frederic Weisbecker | 1 Jun 01:02 2010
Picon

[PATCH 4/4] perf-record: Check correct pid when forking

From: Borislav Petkov <bp <at> alien8.de>

When forking the child to be traced, we should check the correct
return value from fork() and not a local variable which is otherwise
unused.

Signed-off-by: Borislav Petkov <bp <at> alien8.de>
Cc: Ingo Molnar <mingo <at> elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
Cc: Arnaldo Carvalho de Melo <acme <at> redhat.com>
Cc: Paul Mackerras <paulus <at> samba.org>
Cc: Tom Zanussi <tzanussi <at> gmail.com>
Cc: Stephane Eranian <eranian <at> google.com>
LKML-Reference: <20100531211818.GA30175 <at> liondog.tnic>
Signed-off-by: Frederic Weisbecker <fweisbec <at> gmail.com>
---
 tools/perf/builtin-record.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 9bc8905..dc3435e 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
 <at>  <at>  -503,7 +503,6  <at>  <at>  static int __cmd_record(int argc, const char **argv)
 {
 	int i, counter;
 	struct stat st;
-	pid_t pid = 0;
 	int flags;
 	int err;
(Continue reading)

mark gross | 1 Jun 01:03 2010
Picon

Re: [RFC] lp_events: an lternitive to suspend blocker user mode and kernel API

On Mon, May 31, 2010 at 02:55:16AM -0700, Arve Hjønnevåg wrote:
> On Sun, May 30, 2010 at 1:04 PM, mark gross <640e9920 <at> gmail.com> wrote:
> > Low Power Events is a possible alternative to suspend blocker / wake
> > lock API used by Android.
> >
> > It provides comparable power state notification and kernel mode critical
> > section definition.  It differs from suspend blocker in that:
> > 1) it is a platform and device independent implementation.  Device
> > specific code is register as lp_ops, similar to pm_ops.  Drivers use
> > the platform independent functions.
> >
> How is this more platform independent than suspend blockers?

You don't have to do "suspend to ram" for the low power mode and one
could could entertain something different form S2R.

> > 2) it forces a user mode transition coming out of a LP state.
> > Notification of wake up sources go to the user mode process managing the
> > lp states.  Notification of blocked LP state entry is through an
> > error return, and notification of un-blocking is through a file node as
> > well.
> >
> If you want a user mode transition for every resume, you can easily
> get this with the opportunistic suspend patchset by sending an input
> event (or other a custom event with that blocks suspend) from a
> driver's resume hook.

the input event thing looks like a way to go.

> > I think the change need to the Google Android user mode power handling
(Continue reading)

Arnaldo Carvalho de Melo | 1 Jun 01:06 2010

Re: [PATCH v2 1/1] perf tools: Make target to generate self contained source tarball

Em Mon, May 31, 2010 at 10:11:24PM +0200, Michal Marek escreveu:
> On 31.5.2010 19:42, Arnaldo Carvalho de Melo wrote:
> > +git archive --prefix=$(perf-tar)/ HEAD^{tree}                       \
> 
> If you use plain "HEAD" (a commit-ish) instead if HEAD^{tree}, then
> git archive will store the commit id in the archive metadata and the
> user can then use git get-tar-commit-id to extract it.

I just used what was in git.git and then when talking with a git
enthusiast, he showed me this:

[acme <at> emilia git]$ git show 9cd625b79babaf50f50a0e5d96903eaacb1ee600
commit 9cd625b79babaf50f50a0e5d96903eaacb1ee600
Author: Rene Scharfe <rene.scharfe <at> lsrfire.ath.cx>
Date:   Sun Jun 18 15:25:33 2006 +0200

    Make release tarballs friendlier to older tar versions

    git-tar-tree adds an extended pax header to archives if its first
    parameter points to a commit.  It confuses older tars and isn't
    very useful in the case of git anyway, so stop doing it.

    Idea: Junio, implementation: Junio.  I just wrote it up. :-)

    Signed-off-by: Rene Scharfe <rene.scharfe <at> lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <junkio <at> cox.net>

diff --git a/Makefile b/Makefile
index 2a1e639..28517f4 100644
--- a/Makefile
(Continue reading)

James Morris | 1 Jun 01:09 2010

Re: [PATCH v2] fs: block cross-uid sticky symlinks

On Mon, 31 May 2010, Kees Cook wrote:

> Expecting the push-back from VFS, I wrote this patch against commoncaps.
> 
> James, would you take it there (along with the patch to SELinux to call
> out to commoncaps) if there is no way to proceed with the VFS core towards
> solving this?

Isn't this just bypassing the VFS objections?

- James
--

-- 
James Morris
<jmorris <at> namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Arnaldo Carvalho de Melo | 1 Jun 01:11 2010

Re: [PATCH 1/5] perf stat: add perf stat -B to pretty print large numbers

Em Mon, May 31, 2010 at 04:49:02PM -0400, Valdis.Kletnieks <at> vt.edu escreveu:
> the same places, -B or not -B.  I was sort of expecting that the first
> example wouldn't have commas in it, or something?  Or were those two

Right, from a quick read it seems you saw a bug in the changeset and I
saw none in the patch itself.

I've read the intent, tested the patches, found it matched the intent,
happily applied the patch with a confusing/wrong comment, too bad :-\

> examples *supposed* to be identical, and there's a not-shown 3rd example
> that shows what you get if you use -B and set the LC_NUMERIC variable?

- Arnaldo

Gmane