[lkml]   [2008]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86: create array based interface to change page attribute
    Jesse Barnes wrote:
    > On Monday, April 07, 2008 12:51 pm Thomas Hellström wrote:
    >>> Hopefully the WC stuff will be upstream right after 2.6.25 comes out.
    >>> Any reason why we shouldn't keep the pages mapped in the kernel as WC
    >>> assuming the interface is there?
    >> If the pages are unmapped, we can get reasonable speed doing
    >> unbind-read-bind operations, kernel accesses to the memory will need to
    >> use an iomap_atomic_prot_pfn() type of operation.
    >> No IPI global tlb flushes needed for kernel mapping changes during
    >> unbind-read-bind and no cache flushes needed either if we write-protect
    >> the user-space mappings properly, or very limited cache flushes if we
    >> keep dirty-written-while-cached flags for each page.
    >> If the pages are wc-d we'll need two extra IPI global tlb flushes and a
    >> buffer-size cache flush every time we do unbind-read-bind, but OTOH we
    >> don't need the iomap_atomic_prot_pfn() to access single pages from the
    >> kernel.
    > Why would we need to flush at all at unbind-read-bind time? We should be able
    > to leave pages in the WC state even when we unbind them, then when we need to
    > bind them back into the GTT they'll be ready, but maybe I'm misunderstanding
    > you here...
    We want to make the user-space mapping cache-coherent after unbind
    during read, to have any serious read-speed, and the linear kernel map
    has to follow, unless it's non-present. Even if it's non present, we
    need to flush whatever was written through the user-space mapping from
    the cache when rebinding. Having the user-space mapping read-only when
    possible will help avoid this.
    >>> Also, to make the API readable, we'd probably want to split the function
    >>> into kernel_map_pages(..., enum memory_type type) and
    >>> kernel_unmap_pages(...) (though like I said I think we really should be
    >>> mapping them WC not umapping them altogether, since we do want to hit the
    >>> ring buffer from the kernel with the WC type for example).
    >> I think ring-buffers are using ioremap() or vmap() already today. We can
    >> use these to get WC-type access also in the future. The only time we use
    >> the linear kernel mapping today is for single page access while patching
    >> up command buffers.
    > Yeah, they're ioremapped now, but that's a problem since with the PAT patches
    > they'll be mapped hard UC (right now it just happens to work).
    Ouch, so we'll be needing an ioremap_wc(), I guess. We probably
    shouldn't use the linear kernel map for this anyway, since that would
    require a chipset flush for each ring commit. We can actually use
    vmap() with a wc page protection for that, but an ioremap_wc() would
    certainly save us a lot of trouble.
    > Thanks,
    > Jesse

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2008-04-07 22:49    [W:0.031 / U:11.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site