From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.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 19:35:29 +0200 [thread overview]
Message-ID: <1284399329.2275.387.camel@laptop> (raw)
In-Reply-To: <AANLkTimZTzCjea3KFxGcaQ7kscod7sOrz13LkNF_u38w@mail.gmail.com>
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.
next prev parent reply other threads:[~2010-09-13 17:35 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 [this message]
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
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=1284399329.2275.387.camel@laptop \
--to=peterz@infradead.org \
--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=mathieu.desnoyers@efficios.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox