On Wed, Mar 05, 2008 at 10:48:24AM -0800, Christoph Lameter wrote:
On Wed, 5 Mar 2008, Nick Piggin wrote:
Um, it's bound to the *Linux page tables*, yes. And I have no idea why
you would use the paravirt ops for this.
paravirt ops allows interception of page table operations?
Maybe
On Tue, Mar 04, 2008 at 11:35:32AM +0100, Peter Zijlstra wrote:
On Mon, 2008-03-03 at 13:15 -0600, Jack Steiner wrote:
I haven't thought about locking requirements for the radix tree. Most
accesses
would be read-only updates infrequent. Any chance of an RCU-based radix
On Mon, Mar 03, 2008 at 11:01:22AM -0800, Christoph Lameter wrote:
On Mon, 3 Mar 2008, Nick Piggin wrote:
I'm still not completely happy with this. I had a very quick look
at the GRU driver, but I don't see why it can't be implemented
more like the regular TLB model, and have TLB
On Mon, Mar 03, 2008 at 04:29:34AM +0100, Nick Piggin wrote:
to something I prefer. Others may not, but I'll post them for debate
anyway.
Sure, thanks!
I didn't drop invalidate_page, because invalidate_range_begin/end
would be slower for usages like KVM/GRU (we don't need a begin/end
On Mon, Mar 03, 2008 at 01:51:53PM +0100, Andrea Arcangeli wrote:
On Mon, Mar 03, 2008 at 04:29:34AM +0100, Nick Piggin wrote:
to something I prefer. Others may not, but I'll post them for debate
anyway.
Sure, thanks!
I didn't drop invalidate_page, because invalidate_range_begin/end
On Mon, Mar 03, 2008 at 02:10:17PM +0100, Nick Piggin wrote:
Is this just a GRU problem? Can't we just require them to take a ref
on the page (IIRC Jack said GRU could be changed to more like a TLB
model).
Yes, it's just a GRU problem, it tries to optimize performance by
calling follow_page
On Mon, Mar 03, 2008 at 02:10:17PM +0100, Nick Piggin wrote:
On Mon, Mar 03, 2008 at 01:51:53PM +0100, Andrea Arcangeli wrote:
On Mon, Mar 03, 2008 at 04:29:34AM +0100, Nick Piggin wrote:
to something I prefer. Others may not, but I'll post them for debate
anyway.
Sure, thanks!
On Mon, Mar 03, 2008 at 09:18:59AM -0600, Jack Steiner wrote:
On Mon, Mar 03, 2008 at 02:10:17PM +0100, Nick Piggin wrote:
On Mon, Mar 03, 2008 at 01:51:53PM +0100, Andrea Arcangeli wrote:
On Mon, Mar 03, 2008 at 04:29:34AM +0100, Nick Piggin wrote:
to something I prefer. Others may not,
On Mon, Mar 03, 2008 at 05:59:10PM +0100, Nick Piggin wrote:
On Mon, Mar 03, 2008 at 09:18:59AM -0600, Jack Steiner wrote:
On Mon, Mar 03, 2008 at 02:10:17PM +0100, Nick Piggin wrote:
On Mon, Mar 03, 2008 at 01:51:53PM +0100, Andrea Arcangeli wrote:
On Mon, Mar 03, 2008 at 04:29:34AM
Jack Steiner wrote:
The range invalidates have a performance advantage for the GRU. TLB
invalidates
on the GRU are relatively slow (usec) and interfere somewhat with the
performance
of other active GRU instructions. Invalidating a large chunk of addresses with
a single GRU TLBINVAL
On Mon, Mar 03, 2008 at 08:09:49PM +0200, Avi Kivity wrote:
Jack Steiner wrote:
The range invalidates have a performance advantage for the GRU. TLB
invalidates
on the GRU are relatively slow (usec) and interfere somewhat with the
performance
of other active GRU instructions. Invalidating a
On Mon, Mar 03, 2008 at 12:06:05PM -0600, Jack Steiner wrote:
On Mon, Mar 03, 2008 at 05:59:10PM +0100, Nick Piggin wrote:
Maintaining a long-term reference on a page is a problem. The GRU does not
currently maintain tables to track the pages for which dropins have been
done.
The
On Mon, 3 Mar 2008, Nick Piggin wrote:
I'm still not completely happy with this. I had a very quick look
at the GRU driver, but I don't see why it can't be implemented
more like the regular TLB model, and have TLB insertions depend on
the linux pte, and do invalidates _after_ restricting
On Mon, 3 Mar 2008, Nick Piggin wrote:
It is going to be really easy to add more weird and wonderful notifiers
later that deviate from our standard TLB model. It would be much harder to
remove them. So I really want to see everyone conform to this model first.
Numbers and comparisons can be
On Mon, 3 Mar 2008, Nick Piggin wrote:
Move definition of struct mmu_notifier and struct mmu_notifier_ops under
CONFIG_MMU_NOTIFIER to ensure they doesn't get dereferenced when they
don't make sense.
The callbacks take a mmu_notifier parameter. So how does this compile for
!MMU_NOTIFIER?
On Mon, Mar 03, 2008 at 07:45:17PM +0100, Nick Piggin wrote:
On Mon, Mar 03, 2008 at 12:06:05PM -0600, Jack Steiner wrote:
On Mon, Mar 03, 2008 at 05:59:10PM +0100, Nick Piggin wrote:
Maintaining a long-term reference on a page is a problem. The GRU does
not
currently maintain
On Mon, Mar 03, 2008 at 11:01:22AM -0800, Christoph Lameter wrote:
API still has rcu issues and the example given for making things sleepable
is only working for the aging callback. The most important callback is for
try_to_unmao and page_mkclean. This means the API is still not generic
Here an example of the futher orthogonal work to do on top of #v8
during .26-rc to make the whole mmu notifier API sleep capable.
1) Every single ptep_clear_flush_young_notify and
ptep_clear_flush_notify must be converted like the below. The below is
the conversion of a single one. do_wp_page has
Difference between #v7 and #v8:
1) s/age_page/clear_flush_young/ (Nick's suggestion)
2) macro fix (Andrew)
3) move release before final unmap_vmas (for GRU, Jack/Christoph)
4) microoptimize mmu_notifier_unregister (Christoph)
5) use mmap_sem for registration serialization (Christoph)
The
On Sun, Mar 02, 2008 at 04:54:57PM +0100, Andrea Arcangeli wrote:
Difference between #v7 and #v8:
1) s/age_page/clear_flush_young/ (Nick's suggestion)
2) macro fix (Andrew)
3) move release before final unmap_vmas (for GRU, Jack/Christoph)
4) microoptimize mmu_notifier_unregister (Christoph)
On Sun, Mar 02, 2008 at 04:54:57PM +0100, Andrea Arcangeli wrote:
Difference between #v7 and #v8:
[patch] mmu-v8: demacro
Remove the macros from mmu_notifier.h, in favour of functions.
This requires untangling the include order circular dependencies as well,
so just remove struct
On Sun, Mar 02, 2008 at 04:54:57PM +0100, Andrea Arcangeli wrote:
Difference between #v7 and #v8:
This one on top of the previous patch
[patch] mmu-v8: typesafe
Move definition of struct mmu_notifier and struct mmu_notifier_ops under
CONFIG_MMU_NOTIFIER to ensure they doesn't get dereferenced
On Sun, Mar 02, 2008 at 04:54:57PM +0100, Andrea Arcangeli wrote:
Difference between #v7 and #v8:
Here is just a couple of checkpatch fixes on top of the last patches.
Index: linux-2.6/include/linux/mmu_notifier.h
===
---
23 matches
Mail list logo
