On Tue, Oct 13, 2009 at 08:40:06AM +0200, Ingo Molnar wrote:
>
> * Jason Gunthorpe wrote:
>
> > On Mon, Oct 12, 2009 at 10:20:46PM +0200, Ingo Molnar wrote:
> > > It might be more acceptable because the flag-hint mechanism can at most
> > > cause over-flushing - while with perf events we might
* Jason Gunthorpe wrote:
> On Mon, Oct 12, 2009 at 10:20:46PM +0200, Ingo Molnar wrote:
> > It might be more acceptable because the flag-hint mechanism can at most
> > cause over-flushing - while with perf events we might miss to invalidate
> > a range altogether.
>
> Right. Overflushing is n
* Brice Goglin wrote:
> Ingo Molnar wrote:
> > * Jason Gunthorpe wrote:
> >
> >
> >> On Mon, Oct 12, 2009 at 08:19:44PM +0200, Ingo Molnar wrote:
> >>
> >>
> After that point the scheme is perfectly lossless.
>
> >>> Well if it can OOM it's not lossless, obviously. Yo
Ingo Molnar wrote:
> * Jason Gunthorpe wrote:
>
>
>> On Mon, Oct 12, 2009 at 08:19:44PM +0200, Ingo Molnar wrote:
>>
>>
After that point the scheme is perfectly lossless.
>>> Well if it can OOM it's not lossless, obviously. You just define
>>> "event loss" to be equival
On Mon, Oct 12, 2009 at 10:20:46PM +0200, Ingo Molnar wrote:
> It might be more acceptable because the flag-hint mechanism can at most
> cause over-flushing - while with perf events we might miss to invalidate
> a range altogether.
Right. Overflushing is not important, but missing an event entir
* Jason Gunthorpe wrote:
> On Mon, Oct 12, 2009 at 08:19:44PM +0200, Ingo Molnar wrote:
>
> > > After that point the scheme is perfectly lossless.
> >
> > Well if it can OOM it's not lossless, obviously. You just define
> > "event loss" to be equivalent to "Destruction of the universe." ;-)
>
On Mon, Oct 12, 2009 at 08:19:44PM +0200, Ingo Molnar wrote:
> > After that point the scheme is perfectly lossless.
>
> Well if it can OOM it's not lossless, obviously. You just define "event
> loss" to be equivalent to "Destruction of the universe." ;-)
It can't OOM once the ummunotify registr
* Jason Gunthorpe wrote:
> On Wed, Sep 30, 2009 at 11:44:56AM +0200, Ingo Molnar wrote:
> > > > OK. It would be nice to tie into something more general, but I
> > > > think I agree -- perf counters are missing the filtering and the "no
> > > > lost events" that ummunotify does have. [...]
> >
On Wed, 2009-10-07 at 15:34 -0700, Roland Dreier wrote:
> > So I looked a little deeper into this, and I don't think (even with the
> > filtering extensions) that perf events are directly applicable to this
> > problem. The first issue is that, assuming I'm understanding the
> > comment in perf
> So I looked a little deeper into this, and I don't think (even with the
> filtering extensions) that perf events are directly applicable to this
> problem. The first issue is that, assuming I'm understanding the
> comment in perf_event.c:
>
> /*
> * Raw tracepoint data
Hi!
> In the end this seems to just take the ummunotify code I have, and make
> it be a new type of perf counter instead of a character special device.
> I'd actually be OK with that, since having an oddball new char dev
> interface is not particularly nice. But on the other hand just
> multiplex
> Per tracepoint filtering is possible via the perf event patches Li Zefan
> has posted to lkml recently, under this subject:
>
>[PATCH 0/6] perf trace: Add filter support
>
> They are still being worked on but it's very clear that flexible
> in-kernel filtering support will be a na
> Performance events filtering is being worked on and now with the proper
> non-DoS limit you've added you can lose events too, dont you? So it's
> all a question of how much buffering to add - and with perf events too
> you can buffer arbitrary large amount of events.
No, the idea for non
On Wed, Sep 30, 2009 at 11:44:56AM +0200, Ingo Molnar wrote:
> > > OK. It would be nice to tie into something more general, but I
> > > think I agree -- perf counters are missing the filtering and the "no
> > > lost events" that ummunotify does have. [...]
>
> Performance events filtering is be
* Pavel Machek wrote:
> On Thu 2009-09-17 08:45:29, Roland Dreier wrote:
> >
> >
[...]
> > OK. It would be nice to tie into something more general, but I
> > think I agree -- perf counters are missing the filtering and the "no
> > lost events" that ummunotify does have. [...]
Performance ev
On Thu 2009-09-17 08:45:29, Roland Dreier wrote:
>
> > > > Hmm, or are you saying you can only get 1 event per registered range
> and
> > > > allocate the thing on registration? That'd need some registration limit
> > > > to avoid DoS scenarios.
> > >
> > > Yes, that's what I do. You're ri
On Mon, Sep 28, 2009 at 10:49:23PM +0200, Pavel Machek wrote:
> > > I don't remember seeing discussion of this on lkml. Yes it is in
> > > -next...
> >
> > eg http://lkml.org/lkml/2009/7/31/197 and followups, or search for v2
> > and earlier patches.
> Well... it seems little overspecialized
On Tue 2009-09-15 07:57:56, Roland Dreier wrote:
>
> > I don't remember seeing discussion of this on lkml. Yes it is in
> > -next...
>
> eg http://lkml.org/lkml/2009/7/31/197 and followups, or search for v2
> and earlier patches.
Well... it seems little overspecialized. Just modifying libc to
* Roland Dreier wrote:
> > But yeah, I currently don't see a very nice match to perf counters.
>
> OK. It would be nice to tie into something more general, but I think
> I agree -- perf counters are missing the filtering and the "no lost
> events" that ummunotify does have. And I'm not sur
> > > Hmm, or are you saying you can only get 1 event per registered range and
> > > allocate the thing on registration? That'd need some registration limit
> > > to avoid DoS scenarios.
> >
> > Yes, that's what I do. You're right, I should add a limit... although
> > their are lots of way
On Thu, 2009-09-17 at 08:03 -0700, Roland Dreier wrote:
> > Hmm, or are you saying you can only get 1 event per registered range and
> > allocate the thing on registration? That'd need some registration limit
> > to avoid DoS scenarios.
>
> Yes, that's what I do. You're right, I should add a li
> Hmm, or are you saying you can only get 1 event per registered range and
> allocate the thing on registration? That'd need some registration limit
> to avoid DoS scenarios.
Yes, that's what I do. You're right, I should add a limit... although
their are lots of ways for userspace to consume
On Thu, 2009-09-17 at 07:32 -0700, Roland Dreier wrote:
> > So getting those events in the kernel is no problem -- we have the MMU
> > notifier hooks that tell us exactly what we need to know. The issue is
> > purely the way userspace registers interest in address ranges, and how
> > to kernel
On Thu, 2009-09-17 at 07:24 -0700, Roland Dreier wrote:
> > Anton Blanchard suggested a while back that this might be integrated
> > with perf-counters, since perf-counters already does mmap() tracking and
> > also provides events through an mmap()'ed buffer.
> >
> > Has anybody looked into th
> So getting those events in the kernel is no problem -- we have the MMU
> notifier hooks that tell us exactly what we need to know. The issue is
> purely the way userspace registers interest in address ranges, and how
> to kernel returns the events.
>
> For perf counters it seems that one
> Anton Blanchard suggested a while back that this might be integrated
> with perf-counters, since perf-counters already does mmap() tracking and
> also provides events through an mmap()'ed buffer.
>
> Has anybody looked into this?
I didn't see the original suggestion. Certainly hooking in
On Thu, 2009-09-10 at 21:38 -0700, Roland Dreier wrote:
> Linus, please consider pulling from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> ummunotify
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/
On Wed, 16 Sep 2009, Roland Dreier wrote:
>
> Sorry to hassle you about this, but I would like to know where things
> stand. I know (from the reflink discussion if nothing else) that you're
> definitely not bashful about telling people when their code sucks, so
> this silent treatment has me re
Hi Linus,
Sorry to hassle you about this, but I would like to know where things
stand. I know (from the reflink discussion if nothing else) that you're
definitely not bashful about telling people when their code sucks, so
this silent treatment has me really flustered. I've been showering and
bru
> I don't remember seeing discussion of this on lkml. Yes it is in
> -next...
eg http://lkml.org/lkml/2009/7/31/197 and followups, or search for v2
and earlier patches.
> Basically it allows app to 'trace itself'? ...with interesting mmap()
> interface, exporting int to userspace, hoping it
On Sep 15, 2009, at 3:03 AM, KOSAKI Motohiro wrote:
- I guess you have your MPI implementaion w/ ummunotify, right?
- I guess you have test sevaral pattern, right?
if so, can we see your test result?
Roland's answers to the rest of these questions were spot-on, so I
thought I'd just t
Hi!
> Linus, please consider pulling from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> ummunotify
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
> ummunotify
>
> This will
> - I guess you have your MPI implementaion w/ ummunotify, right?
Yes, Jeff Squyres (cc'ed) has an Open MPI prototype (mercurial tree at
http://bitbucket.org/jsquyres/ummunot/).
> - I guess you have test sevaral pattern, right?
>if so, can we see your test result?
Open MPI has a pretty
>
> > So.. What is the problem with fork? The semantics of what should
> > happen seem natural enough to me, the PD doesn't get copied to the
> > child, so the MR stays with the parent. COW events on the pinned
> > region must be resolved so that the physical page stays with the
> > process t
> So.. What is the problem with fork? The semantics of what should
> happen seem natural enough to me, the PD doesn't get copied to the
> child, so the MR stays with the parent. COW events on the pinned
> region must be resolved so that the physical page stays with the
> process that has pinn
On Fri, Sep 11, 2009 at 03:11:36PM +0900, KOSAKI Motohiro wrote:
> Hi
>
> Thank you explanation.
>
> >
> > > Can I this version already solved fork() + COW issue? if so, could you
> > > please explain what happen at fork. Obviously RDMA point to either parent
> > > or child page, not both. bu
On Thu, Sep 10, 2009 at 11:22:20PM -0700, Roland Dreier wrote:
> As I said, it does mean that MPI can invalidate cached registrations for
> COWed memory, which might be useful in case a parent forks and then
> touches memory it used to use for RDMA, but I think that's the easier
> part of the fork
Roland Dreier wrote:
> > Can I this version already solved fork() + COW issue? if so, could you
> > please explain what happen at fork. Obviously RDMA point to either parent
> > or child page, not both. but Corrent COW rule is, first touch process
> > get copyed page and other process still own
> My understanding of the code is that fork will end-up calling
> copy_page_range() on all VMA, and copy_page_range() calls
> mmu_notifier_invalidate_range_start() if is_cow_mapping() is true,
> which should be the case here. So you should get some invalidate events
> on fork.
Yes, I agree
> Roland Dreier wrote:
> > > Can I this version already solved fork() + COW issue? if so, could you
> > > please explain what happen at fork. Obviously RDMA point to either parent
> > > or child page, not both. but Corrent COW rule is, first touch process
> > > get copyed page and other process
Hi
Thank you explanation.
>
> > Can I this version already solved fork() + COW issue? if so, could you
> > please explain what happen at fork. Obviously RDMA point to either parent
> > or child page, not both. but Corrent COW rule is, first touch process
> > get copyed page and other process
> Can I this version already solved fork() + COW issue? if so, could you
> please explain what happen at fork. Obviously RDMA point to either parent
> or child page, not both. but Corrent COW rule is, first touch process
> get copyed page and other process still own original page. I think it's
Hi Roland,
> Linus, please consider pulling from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> ummunotify
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
> ummunotify
>
> Thi
Linus, please consider pulling from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git ummunotify
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
ummunotify
This will get "ummunotify," a new char
44 matches
Mail list logo
