On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
> With regard to the synchronize_rcu troubles they also be left to the
> notifier-user to solve. Certainly having the synchronize_rcu like in
Ahh. Ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Mon, Jan 28, 2008 at 11:04:43AM -0800, Christoph Lameter wrote:
> On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
>
> > So I'd like to know what can we do to help to merge the 4 patches from
> > Christoph in mainline, I'd appreciate comments on them so we can help
> > to address any outstanding
On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
> So I'd like to know what can we do to help to merge the 4 patches from
> Christoph in mainline, I'd appreciate comments on them so we can help
> to address any outstanding issue!
There are still some pending issues (RCU troubles). I will post V2
On Mon, Jan 28, 2008 at 06:10:39PM +0200, Izik Eidus wrote:
> i dont understand how is that better than notification on tlb flush?
I certainly agree. The quoted call wasn't actually the one that could
be moved in a single place in the .h file though. But the 4/4 patch
could be reduced to a few
Andrea Arcangeli wrote:
On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
Andrea's mmu_notifier #4 -> RFC V1
- Merge subsystem rmap based with Linux rmap based approach
- Move Linux rmap based notifiers out of macro
- Try to account for what locks are held while the
On Mon, Jan 28, 2008 at 11:04:43AM -0800, Christoph Lameter wrote:
On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
So I'd like to know what can we do to help to merge the 4 patches from
Christoph in mainline, I'd appreciate comments on them so we can help
to address any outstanding issue!
On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
With regard to the synchronize_rcu troubles they also be left to the
notifier-user to solve. Certainly having the synchronize_rcu like in
Ahh. Ok.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Mon, 28 Jan 2008, Andrea Arcangeli wrote:
So I'd like to know what can we do to help to merge the 4 patches from
Christoph in mainline, I'd appreciate comments on them so we can help
to address any outstanding issue!
There are still some pending issues (RCU troubles). I will post V2 today.
On Mon, Jan 28, 2008 at 06:10:39PM +0200, Izik Eidus wrote:
i dont understand how is that better than notification on tlb flush?
I certainly agree. The quoted call wasn't actually the one that could
be moved in a single place in the .h file though. But the 4/4 patch
could be reduced to a few
Andrea Arcangeli wrote:
On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
Andrea's mmu_notifier #4 - RFC V1
- Merge subsystem rmap based with Linux rmap based approach
- Move Linux rmap based notifiers out of macro
- Try to account for what locks are held while the
On Sat, 26 Jan 2008, Benjamin Herrenschmidt wrote:
> Also, wouldn't there be a problem with something trying to use that
> interface to keep in sync a secondary device MMU such as the DRM or
> other accelerators, which might need virtual address based
> invalidation ?
Yes just doing the rmap
On Fri, 2008-01-25 at 12:42 +0100, Andrea Arcangeli wrote:
> On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
> > Andrea's mmu_notifier #4 -> RFC V1
> >
> > - Merge subsystem rmap based with Linux rmap based approach
> > - Move Linux rmap based notifiers out of macro
> > - Try
On Fri, 25 Jan 2008, Andrea Arcangeli wrote:
> On a technical merit this still partially makes me sick and I think
> it's the last issue to debate.
>
> @@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
> else
> ret = try_to_unmap_file(page, migration);
>
> +
On Fri, Jan 25, 2008 at 12:42:29PM +0100, Andrea Arcangeli wrote:
> On a technical merit this still partially makes me sick and I think
> it's the last issue to debate.
>
> @@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
> else
> ret = try_to_unmap_file(page,
On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
> Andrea's mmu_notifier #4 -> RFC V1
>
> - Merge subsystem rmap based with Linux rmap based approach
> - Move Linux rmap based notifiers out of macro
> - Try to account for what locks are held while the notifiers are
> called.
>
On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
Andrea's mmu_notifier #4 - RFC V1
- Merge subsystem rmap based with Linux rmap based approach
- Move Linux rmap based notifiers out of macro
- Try to account for what locks are held while the notifiers are
called.
-
On Sat, 26 Jan 2008, Benjamin Herrenschmidt wrote:
Also, wouldn't there be a problem with something trying to use that
interface to keep in sync a secondary device MMU such as the DRM or
other accelerators, which might need virtual address based
invalidation ?
Yes just doing the rmap based
On Fri, 2008-01-25 at 12:42 +0100, Andrea Arcangeli wrote:
On Thu, Jan 24, 2008 at 09:56:06PM -0800, Christoph Lameter wrote:
Andrea's mmu_notifier #4 - RFC V1
- Merge subsystem rmap based with Linux rmap based approach
- Move Linux rmap based notifiers out of macro
- Try to account
On Fri, 25 Jan 2008, Andrea Arcangeli wrote:
On a technical merit this still partially makes me sick and I think
it's the last issue to debate.
@@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
else
ret = try_to_unmap_file(page, migration);
+ if
On Fri, Jan 25, 2008 at 12:42:29PM +0100, Andrea Arcangeli wrote:
On a technical merit this still partially makes me sick and I think
it's the last issue to debate.
@@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
else
ret = try_to_unmap_file(page,
This is a patchset implementing MMU notifier callbacks based on Andrea's
earlier work. These are needed if Linux pages are referenced from something
else than tracked by the rmaps of the kernel.
To do:
- Make locking requirements for the callbacks consistent and
document them accurately.
-
This is a patchset implementing MMU notifier callbacks based on Andrea's
earlier work. These are needed if Linux pages are referenced from something
else than tracked by the rmaps of the kernel.
To do:
- Make locking requirements for the callbacks consistent and
document them accurately.
-
22 matches
Mail list logo
