All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, paulus@samba.org,
	davem@davemloft.net, fweisbec@gmail.com,
	perfmon2-devel@lists.sf.net, eranian@gmail.com,
	robert.richter@amd.com, acme@redhat.com, lizf@cn.fujitsu.com
Subject: Re: [PATCH 1/2] perf_events: add support for per-cpu per-cgroup monitoring (v5)
Date: Thu, 25 Nov 2010 16:02:24 +0100	[thread overview]
Message-ID: <1290697344.2145.56.camel@laptop> (raw)
In-Reply-To: <AANLkTi=J8eRKjb8BBsDjaxnsvvuSLbZw2CN4k3YFGM+Y@mail.gmail.com>

On Thu, 2010-11-25 at 15:51 +0100, Stephane Eranian wrote:
> 
> 
> On Thu, Nov 25, 2010 at 12:20 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>         On Thu, 2010-11-18 at 12:40 +0200, Stephane Eranian wrote:
>         > @@ -919,6 +945,10 @@ static inline void perf_event_task_sched_in(struct task_struct *task)
>         >  static inline
>         >  void perf_event_task_sched_out(struct task_struct *task, struct task_struct *next)
>         >  {
>         > +#ifdef CONFIG_CGROUPS
>         > +       atomic_t *cgroup_events = &__get_cpu_var(perf_cgroup_events);
>         > +       COND_STMT(cgroup_events, perf_cgroup_switch(task, next));
>         > +#endif
>         >         COND_STMT(&perf_task_events, __perf_event_task_sched_out(task, next));
>         >  }
>         
>         
>         I don't think that'll actually work, the jump label stuff needs a static
>         address.
>         
> I did not know that.

Yeah, its unfortunate the fallback code doesn't mandate this :/


>         Why not simply: s/perf_task_events/perf_sched_events/ and
>         increment it
>         for cgroup events as well?
>         
> But you would need to demultiplex. that's not because perf_sched_events is
> set that you want BOTH perf_cgroup_switch() AND perf_event_task_sched_out(). 

The main purpose of the jump-label stuff is to optimize the function
call and conditional into the perf code away, the moment we a function
call we might as well do everything, at that point its only a single
conditional.

Jump labels are supposed to work like (they don't actually work like
this yet):

my_func:
    asm-foo
addr_of_nop:
    nop5
after_nop:
    more-asm-foo
    iret

out_of_line:
    do-special-foo
    jmp after_nop


We then keep a section of tuples:

__jump_labels:

  &perf_task_events,addr_of_nop

Then when we flip perf_task_events from 0 -> !0 we rewrite the nop5 at
addr_of_nop to "jmp out_of_line" (5 bytes on x86, hence nop5), or the
reverse on !0 -> 0.


So 1) we need the 'key' (&perf_task_events) to be a static address
because the compiler needs to place the address in the special section
-- otherwise we can never find the nop location again, this also means
per-cpu variables don't make sense, there's only 1 copy of the text.

and 2) the moment we take the out-of-line branch we incur the icache hit
and already set up a call, so optimizing away another conditional at the
cost of an extra function call doesn't really make sense.




  parent reply	other threads:[~2010-11-25 15:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-18 10:40 [PATCH 1/2] perf_events: add support for per-cpu per-cgroup monitoring (v5) Stephane Eranian
2010-11-25 11:20 ` Peter Zijlstra
2010-11-25 14:53   ` Stephane Eranian
     [not found]   ` <AANLkTi=J8eRKjb8BBsDjaxnsvvuSLbZw2CN4k3YFGM+Y@mail.gmail.com>
2010-11-25 15:02     ` Peter Zijlstra [this message]
2010-11-25 21:32       ` Stephane Eranian
2010-11-26 11:16         ` Peter Zijlstra
2010-11-25 11:28 ` Peter Zijlstra
2010-11-26  1:50   ` Li Zefan
2010-11-26  2:56     ` Balbir Singh
2010-11-26  8:28       ` Li Zefan
2010-11-26 11:28         ` Peter Zijlstra
2010-11-26 11:17       ` 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=1290697344.2145.56.camel@laptop \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=davem@davemloft.net \
    --cc=eranian@gmail.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=perfmon2-devel@lists.sf.net \
    --cc=robert.richter@amd.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.