All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	linux-kernel@vger.kernel.org, mingo@elte.hu, paulus@samba.org,
	davem@davemloft.net, perfmon2-devel@lists.sf.net,
	eranian@gmail.com, robert.richter@amd.com,
	"markus.t.metzger" <markus.t.metzger@intel.com>
Subject: Re: [PATCH] perf_events: improve DS/BTS/PEBS buffer allocation
Date: Mon, 13 Sep 2010 15:31:20 -0400	[thread overview]
Message-ID: <20100913193120.GA28294@Krystal> (raw)
In-Reply-To: <AANLkTi=DGnP-r++PhzWFMdwdu_ReUKAmGLCA2zPNBG5J@mail.gmail.com>

* Stephane Eranian (eranian@google.com) wrote:
> On Mon, Sep 13, 2010 at 7:35 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, 2010-09-13 at 17:55 +0200, Stephane Eranian wrote:
> >>
> >> Ok, so you're saying there is no allocator that will give non-contiguous
> >> physical memory WITHOUT requiring a page fault to populate the pte.
> >>
> >> On the other hand, with vmalloc_node() the pte are populated when
> >> you first touch the memory. That happens as part of memset() right after
> >> the allocation and thus outside of NMI interrupt handler.
> >>
> >> Does this sound right?
> >
> > Nope, in particular read: http://lkml.org/lkml/2010/7/14/465
> >
> > The issue is that the vmalloc space can be mapped in different
> > processes, and that memset() will only ensure its mapped in the current
> > process, but the next one might need that fault to populate.
> >
> Ok, so can we play the same trick you're playing with the sampling
> buffer, i.e., you use alloc_pages_node() for one page at a time, and
> then you stitch them on demand via SW?

Well, a thought is striking me: it sounds like you are re-doing YAORB (short
for Yet Another Ring Buffer, which I start to expect will become a frequently
used acronym). Have you looked at my "generic ring buffer library" ? It's at:

git://git.kernel.org/pub/scm/linux/kernel/git/compudj/linux-2.6-ringbuffer.git
current branch: tip-current-ringbuffer-0.248

documentation is under Documentation/ringbuffer/.

I think it can save you a lot of trouble. E.g., it does stitch pages togeter by
software.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

  parent reply	other threads:[~2010-09-13 19:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 14:55 [PATCH] perf_events: improve DS/BTS/PEBS buffer allocation Stephane Eranian
2010-09-13 15:08 ` Peter Zijlstra
2010-09-13 15:21   ` Stephane Eranian
2010-09-13 15:09 ` Frederic Weisbecker
2010-09-13 15:13   ` Stephane Eranian
2010-09-13 15:16     ` Peter Zijlstra
2010-09-13 15:20       ` Stephane Eranian
2010-09-13 15:24         ` Peter Zijlstra
2010-09-13 15:31           ` Stephane Eranian
2010-09-13 15:41             ` Peter Zijlstra
2010-09-13 15:51               ` Frederic Weisbecker
2010-09-13 15:55               ` Stephane Eranian
2010-09-13 17:35                 ` Peter Zijlstra
2010-09-13 18:40                   ` Stephane Eranian
2010-09-13 18:42                     ` Peter Zijlstra
2010-09-13 18:49                       ` Stephane Eranian
2010-09-13 18:57                         ` Peter Zijlstra
2010-09-13 19:12                           ` Stephane Eranian
2010-09-13 19:31                     ` Mathieu Desnoyers [this message]
2010-09-13 19:34                       ` Peter Zijlstra
2010-09-13 19:35                         ` Peter Zijlstra
2010-09-13 19:42                         ` Mathieu Desnoyers
2010-09-13 17:24               ` Stephane Eranian
2010-09-13 17:36                 ` Peter Zijlstra
2010-09-13 19:35 ` Andi Kleen
2010-09-13 19:49   ` Peter Zijlstra
2010-09-13 20:51     ` Andi Kleen
2010-09-13 20:57       ` [perfmon2] " Luck, Tony
2010-09-13 20:34   ` H. Peter Anvin

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=20100913193120.GA28294@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --cc=davem@davemloft.net \
    --cc=eranian@gmail.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@intel.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=perfmon2-devel@lists.sf.net \
    --cc=peterz@infradead.org \
    --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.