mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Mike Galbraith <efault@gmx.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [PATCH 5/6] perf_counter: kerneltop: mmap_pages argument
Date: Wed, 25 Mar 2009 13:35:14 +0100	[thread overview]
Message-ID: <20090325123514.GB28639@elte.hu> (raw)
In-Reply-To: <1237984033.7972.865.camel@twins>


* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Wed, 2009-03-25 at 13:18 +0100, Ingo Molnar wrote:
> > * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > 
> > > provide a knob to set the number of mmap data pages.
> > 
> > > +	" -m pages  --mmap_pages=<pages> # number of mmap data pages\n"
> > 
> > Btw., we really want this to be auto-tuning to a large degree. If 
> > the kernel observes missed events, it should create a 
> > PERF_EVENT_OVERFLOW==0x3 record, with the number of missed events - 
> > or something like that.
> 
> Well, who's to say we ever see that overflow record if we're 
> having trouble tracking the output as is?

it would overwrite the last (new) record - so it's deterministic and 
the tail does not consume the head - just bites itself a bit.

But it would still be somewhat racy, if user-space _just_ managed to 
process those records ...

> How important is it for people to have accurate overflow 
> information other than the current -- we can't keep up -- kind?

it's somewhat important and could pave the way for the kernel to 
react to overflow more intelligently (via iterim buffering or 
whatever future mechanism).

It's also a general quality of implementation principle for kernel 
code: if we want to hide information we want to hide it from 
_user-space_, not the kernel. Hiding information from the kernel 
almost always causes trouble down the line.

> One possible solution is making the control page writable and 
> writing the userspace read position to it, then the kernel can, on 
> perf_output_begin() detect the overflow and count the number of 
> overwritten events.
> 
> This overflow count could then be published back into the control 
> page.

Ok, that's a nice idea - it keeps the amount of dirty cachelines 
minimal.

> TBH I'm not much of a fan, making all these pages writable just 
> opens a whole can of worms, and that accurate overflow tracking 
> will put more code in the output path.

What can of worms can you see there? (It would not be COW-ed - if 
you share those pages without knowing that they are shared then 
confused user-space will have to keep broken pieces of iteself.)

> Also, when mixing streams (events,mmap) is a single: you missed 
> 'n' events still good?

How would such mixing work? Multiple counters streaming into the 
same mmap area?

	Ingo

  reply	other threads:[~2009-03-25 12:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-25 11:30 [PATCH 0/6] perf_counter: new output ABI Peter Zijlstra
2009-03-25 11:30 ` [PATCH 1/6] perf_counter: more elaborate write API Peter Zijlstra
2009-03-25 12:06   ` [tip:perfcounters/core] " Peter Zijlstra
2009-03-25 11:30 ` [PATCH 2/6] perf_counter: output objects Peter Zijlstra
2009-03-25 12:06   ` [tip:perfcounters/core] " Peter Zijlstra
2009-03-25 11:30 ` [PATCH 3/6] perf_counter: sanity check on the output API Peter Zijlstra
2009-03-25 12:06   ` [tip:perfcounters/core] " Peter Zijlstra
2009-03-25 11:30 ` [PATCH 4/6] perf_counter: optionally provide the pid/tid of the sampled task Peter Zijlstra
2009-03-25 12:06   ` [tip:perfcounters/core] " Peter Zijlstra
2009-03-25 11:30 ` [PATCH 5/6] perf_counter: kerneltop: mmap_pages argument Peter Zijlstra
2009-03-25 12:07   ` [tip:perfcounters/core] " Peter Zijlstra
2009-03-25 12:18   ` [PATCH 5/6] " Ingo Molnar
2009-03-25 12:27     ` Peter Zijlstra
2009-03-25 12:35       ` Ingo Molnar [this message]
2009-03-25 12:41         ` Peter Zijlstra
2009-03-25 12:54           ` Ingo Molnar
2009-03-25 12:57             ` Peter Zijlstra
2009-03-25 14:52               ` Peter Zijlstra
2009-03-25 17:16                 ` Ingo Molnar
2009-03-25 21:18                   ` Peter Zijlstra
2009-03-26  2:22       ` Paul Mackerras
2009-03-25 11:30 ` [PATCH 6/6] perf_counter: kerneltop: output event support Peter Zijlstra
2009-03-25 12:07   ` [tip:perfcounters/core] " Peter Zijlstra
2009-04-04  0:21   ` [PATCH 6/6] " Corey Ashford
2009-04-04 12:17     ` Peter Zijlstra
2009-04-04 18:10       ` Corey Ashford
2009-03-25 12:05 ` [PATCH 0/6] perf_counter: new output ABI Ingo Molnar

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=20090325123514.GB28639@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=efault@gmx.de \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.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

all inboxes | Powered by JetHome®