Ben,
I've implemented a version of the drm_mm code that unmaps ptes using
unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for
a single page in nopage. This has the side effect that I need to double
check in nopage() after taking the object mutex that the pte in question
On Thu, 2006-10-05 at 17:52 +0200, Thomas Hellström wrote:
Ben,
I've implemented a version of the drm_mm code that unmaps ptes using
unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for
a single page in nopage. This has the side effect that I need to double
check in
On Thu, 2006-10-05 at 17:52 +0200, Thomas Hellström wrote:
Ben,
I've implemented a version of the drm_mm code that unmaps ptes using
unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for
a single page in nopage. This has the side effect that I need to double
check in
Benjamin Herrenschmidt wrote:
OK. It seems like mmap locks are needed even for
unmap_mapping_range().
Well, I came to the opposite conclusion :) unmap_mapping_range() uses
the truncate count mecanism to guard against a racing no_page().
The idea is that:
no_page()
OK. i was reffering to another approach: Copying _to_ VRAM /AGP:
lock_mmap_sems()
unmap_mapping_range() (or similar)
copy() / flip()
foreach_affected_vma{
io_remap_pfn_range() /* Map vram / AGP space */
}
unlock_mmap_sem()
This works like a charm in the drm memory manager but it
* objects have rwsem to protect migration.
* no_page() does:
- takes that object read sem
- if object is in vram or other non-memory location then do
io_remap_pfn_range() and get a dummy page struct pointer
- else get the struct page of the object page in memory
- release the
Benjamin Herrenschmidt wrote:
OK. i was reffering to another approach: Copying _to_ VRAM /AGP:
lock_mmap_sems()
unmap_mapping_range() (or similar)
copy() / flip()
foreach_affected_vma{
io_remap_pfn_range() /* Map vram / AGP space */
}
unlock_mmap_sem()
This works like a charm in the drm
I'm finding this an interesting discussion. If it shifts to lkml, for
instance, is there a way to follow *and post* on the thread without
either subscribing to lkml or requiring myself to be on the CC list?
I don't know if lkml allows non-subscriber posted, I think it does tho.
So you can
On Thu, Sep 21, 2006 at 07:18:07PM +1000, Benjamin Herrenschmidt wrote:
I'm finding this an interesting discussion. If it shifts to lkml, for
instance, is there a way to follow *and post* on the thread without
either subscribing to lkml or requiring myself to be on the CC list?
I
No, that's probably the safest approach we can use until NOPAGE_RETRY
arrives.
Only I was not sure it'd be safe to call io_remap_pfn_range() from
within nopage, in case it modifies some internal mm structs that the
kernel nopage() code
expects to be untouched.
It does a couple of things
Ville Syrjälä wrote:
On Thu, Sep 21, 2006 at 07:18:07PM +1000, Benjamin Herrenschmidt wrote:
I'm finding this an interesting discussion. If it shifts to lkml, for
instance, is there a way to follow *and post* on the thread without
either subscribing to lkml or requiring myself to be on the
Benjamin Herrenschmidt wrote:
No, that's probably the safest approach we can use until NOPAGE_RETRY
arrives.
Only I was not sure it'd be safe to call io_remap_pfn_range() from
within nopage, in case it modifies some internal mm structs that the
kernel nopage() code
expects to be untouched.
Hmm, the comments to handle_pte_fault(), which is calling do_nopage
gives some insight..
* Note the page_table_lock. It is to protect against kswapd removing
* pages from under us. Note that kswapd only ever _removes_ pages, never
* adds them. As such, once we have noticed that the
Thomas Hellström wrote:
Benjamin Herrenschmidt wrote:
Hmm, the comments to handle_pte_fault(), which is calling do_nopage
gives some insight..
* Note the page_table_lock. It is to protect against kswapd removing
* pages from under us. Note that kswapd only ever _removes_ pages, never
*
Benjamin Herrenschmidt wrote:
On Tue, 2006-09-19 at 12:49 +0200, Thomas Hellström wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
But this should be the same problem encountered by the
I don't think so.
We are not doing vram yet in the TTM code, but I think a general
eviction would consist of
1) locking mmap_sems for all processes mapping the buffer.
2) zap the page table. Any attempt to access will be blocked by
mmap_sem in nopage().
3) Copy contents from vram to
OK. It seems like mmap locks are needed even for
unmap_mapping_range().
Well, I came to the opposite conclusion :) unmap_mapping_range() uses
the truncate count mecanism to guard against a racing no_page().
The idea is that:
no_page() itself internally takes the per-obkect lock/mutex
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
But this should be the same problem encountered by the agpgart driver?
x86 and x86-64 calls change_page_attr() to take care of this.
On powerpc it is simply a noop. (asm/agp.h)
Possibly. We sort-of ignore the issue for now on PowerPC
Benjamin Herrenschmidt wrote:
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
But this should be the same problem encountered by the agpgart driver?
x86 and x86-64 calls change_page_attr() to take care of this.
On powerpc it is simply a noop. (asm/agp.h)
Thomas Hellström wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:
But this should be the same problem encountered by the agpgart driver?
x86 and x86-64 calls change_page_attr() to take care of this.
On powerpc it is simply a noop.
Dave Airlie wrote:
Obviously, we are interested in making use of the new DRM memory manager
on that hardware. Now if I understand how it works correctly, this new
memory manager allocates opaque handles which are not to be used as
offset in memory, because they are not. Therefore, a
Yes, this is really a different hardware model than we're used to
dealing with for DRI drivers, however it's not a problem for the most
part - if you don't need to take the lock, don't. But then you need
some other way of dealing with the other hacky stuff we get away with by
lock
Benjamin Herrenschmidt wrote:
Yes, this is really a different hardware model than we're used to
dealing with for DRI drivers, however it's not a problem for the most
part - if you don't need to take the lock, don't. But then you need
some other way of dealing with the other hacky
Actually, the TTM memory manager already does this,
but also changes the caching policy of the linear kernel map.
The later is not portable unfortunately, and can have other serious
performance impacts.
Typically, the kernel linear map is mapped using larger page sizes, or
in some cases,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
Extending the memory manager would involve adding an ability to lock and
unlock surfaces to VRAM/AGP addresses - this would require kernel
interaction I guess. The driver would have to lock the surfaces then be
free to
On Mon, 2006-09-18 at 16:46 +0200, Thomas Hellström wrote:
Unfortunately this leads to rather costly cache and TLB flushes.
Particularly on SMP.
I think Keith was referring to the drawbacks with buffers pinned in
AGP or VRAM space.
What about a futex-like approach:
A shared are mapped by
Hello,
Before explaining the issue, let me first introduce the context a bit.
We are working on hardware that supports multiple contexts. By
allocating one context to each application, we can achieve full graphics
command submission from user space (each context is actually simply a
command
Obviously, we are interested in making use of the new DRM memory manager
on that hardware. Now if I understand how it works correctly, this new
memory manager allocates opaque handles which are not to be used as
offset in memory, because they are not. Therefore, a translation from
the handle
28 matches
Mail list logo
