search for: kunmap

On Tue, Mar 12, 2019 at 01:53:37PM -0700, James Bottomley wrote: > I've got to say: optimize what? What code do we ever have in the > kernel that kmap's a page and then doesn't do anything with it? You can > guarantee that on kunmap the page is either referenced (needs > invalidating) or updated (needs flushing). The in-kernel use of kmap is > always > > kmap > do something with the mapped page > kunmap > > In a very short interval. It seems just a simplification to make > kunmap do the flush if n...

...??? int bit = nr + (log % PAGE_SIZE) * 8; > ??????? int r; > > ??????? r = get_user_pages_fast(log, 1, 1, &page); > ??????? if (r < 0) > ??????????????? return r; > ??????? BUG_ON(r != 1); > ??????? base = kmap_atomic(page); > ??????? set_bit(bit, base); > ??????? kunmap_atomic(base); > ??????? set_page_dirty_lock(page); > ??????? put_page(page); > ??????? return 0; > } > > Thanks I think you are right. The correct fix though is to re-implement it using asm and handling pagefault, not gup. Three atomic ops per bit is way to expensive. -- MST

...??? int bit = nr + (log % PAGE_SIZE) * 8; > ??????? int r; > > ??????? r = get_user_pages_fast(log, 1, 1, &page); > ??????? if (r < 0) > ??????????????? return r; > ??????? BUG_ON(r != 1); > ??????? base = kmap_atomic(page); > ??????? set_bit(bit, base); > ??????? kunmap_atomic(base); > ??????? set_page_dirty_lock(page); > ??????? put_page(page); > ??????? return 0; > } > > Thanks I think you are right. The correct fix though is to re-implement it using asm and handling pagefault, not gup. Three atomic ops per bit is way to expensive. -- MST

...; At least for -stable, we need the flush? > > > > > > > > > > Three atomic ops per bit is way to expensive. > > > > > > > > > Yes. > > > > > > Thanks > > > > See James's reply - I stand corrected we do kunmap so no need to > > flush. > > Well, I said that's what we do on Parisc. The cachetlb document > definitely says if you alter the data between kmap and kunmap you are > responsible for the flush. It's just that flush_dcache_page() is a no- > op on x86 so they never rem...

..._HIGHMEM_INTERNAL_H +#define _LINUX_HIGHMEM_INTERNAL_H + +/* + * Outside of CONFIG_HIGHMEM to support X86 32bit iomap_atomic() cruft. + */ +#ifdef CONFIG_KMAP_LOCAL +void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot); +void *__kmap_local_page_prot(struct page *page, pgprot_t prot); +void kunmap_local_indexed(void *vaddr); +#endif + +#ifdef CONFIG_HIGHMEM +#include <asm/highmem.h> + +#ifndef ARCH_HAS_KMAP_FLUSH_TLB +static inline void kmap_flush_tlb(unsigned long addr) { } +#endif + +#ifndef kmap_prot +#define kmap_prot PAGE_KERNEL +#endif + +void *kmap_high(struct page *page); +void...

...; > On Tue, Mar 12, 2019 at 01:53:37PM -0700, James Bottomley wrote: > > > I've got to say: optimize what? What code do we ever have in the > > > kernel that kmap's a page and then doesn't do anything with it? You > > > can > > > guarantee that on kunmap the page is either referenced (needs > > > invalidating) or updated (needs flushing). The in-kernel use of > > > kmap is > > > always > > > > > > kmap > > > do something with the mapped page > > > kunmap > > > > > >...

Generic fbdev emulation needs this. Also: We must keep track of the number of mappings now, so we don't unmap early in case two users want a kmap of the same bo. Add a sanity check to destroy callback to make sure kmap/kunmap is balanced. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 1 + drivers/gpu/drm/qxl/qxl_object.c | 6 ++++++ drivers/gpu/drm/qxl/qxl_prime.c | 17 +++++++++++++---- 3 files changed, 20 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/dr...

On Tue, Mar 12, 2019 at 01:53:37PM -0700, James Bottomley wrote: > I've got to say: optimize what? What code do we ever have in the > kernel that kmap's a page and then doesn't do anything with it? You can > guarantee that on kunmap the page is either referenced (needs > invalidating) or updated (needs flushing). The in-kernel use of kmap is > always > > kmap > do something with the mapped page > kunmap > > In a very short interval. It seems just a simplification to make > kunmap do the flush if n...

...ck_irqsave(&pa_tlb_lock, flags) #define purge_tlb_end(flags) spin_unlock_irqrestore(&pa_tlb_lock, flags) You got a system-wide spinlock in there that won't just go away the second time. So it's a bit more than a tightly pipelined "noop". Your logic of adding the flush on kunmap makes sense, all I'm saying is that it's sacrificing some performance for safety. You asked "optimized what", I meant to optimize away all the above quoted code that will end running twice for each vhost set_bit when it should run just once like in other archs. And it clearly paid...

...c *crtc, } } } - memcpy_toio(pixels_prev->kmap.virtual + row*48, &this_row[0], 48); + memcpy_toio(dst + row*48, &this_row[0], 48); } /* Program gpu address of cursor buffer */ @@ -247,9 +244,9 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, } ret = 0; - ttm_bo_kunmap(&pixels_prev->kmap); + drm_gem_vram_kunmap(pixels_prev); out3: - ttm_bo_kunmap(&gbo->kmap); + drm_gem_vram_kunmap(gbo); out2: drm_gem_vram_unreserve(gbo); out1: diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h index 16ce6b338dce..6180a...

...er. */ if (size - bytes_copied > PAGE_SIZE - page_offset) /* Enough payload to fill up from this page. */ @@ -356,7 +376,8 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue, err = memcpy_fromiovec((u8 *)va + page_offset, iov, to_copy); if (err != 0) { - kunmap(kernel_if->page[page_index]); + if (kernel_if->host) + kunmap(kernel_if->u.h.page[page_index]); return VMCI_ERROR_INVALID_ARGS; } } else { @@ -365,7 +386,8 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue, } bytes_copied += to_copy; - kunmap(kernel_if...

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 11 Mar 2019 09:59:28 -0400 > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: >> >> On 2019/3/8 ??10:12, Christoph Hellwig wrote: >> > On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote: >> > > This series tries to access virtqueue metadata through kernel virtual

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 11 Mar 2019 09:59:28 -0400 > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: >> >> On 2019/3/8 ??10:12, Christoph Hellwig wrote: >> > On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote: >> > > This series tries to access virtqueue metadata through kernel virtual

...a = kmap(kernel_if->page[page_index]); if (size - bytes_copied > PAGE_SIZE - page_offset) /* Enough payload to fill up from this page. */ @@ -388,8 +365,7 @@ static int __qp_memcpy_to_queue(struct vmci_queue *queue, } bytes_copied += to_copy; - if (!kernel_if->mapped) - kunmap(kernel_if->page[page_index]); + kunmap(kernel_if->page[page_index]); } return VMCI_SUCCESS; @@ -417,11 +393,7 @@ static int __qp_memcpy_from_queue(void *dest, void *va; size_t to_copy; - if (!kernel_if->mapped) - va = kmap(kernel_if->page[page_index]); - else - va =...

Hi all, this series removes most users of the write_one_page API. These helpers internally call ->writepage which we are gradually removing from the kernel. Changes since v2: - more minix error handling fixes Changes since v1: - drop the btrfs changes (queue up in the btrfs tree) - drop the finaly move to jfs (can't be done without the btrfs patches) - fix the existing minix code to

...tglx at linutronix.de> --- include/linux/highmem.h | 63 +++--------------------------------------------- mm/highmem.c | 7 ----- 2 files changed, 5 insertions(+), 65 deletions(-) --- a/include/linux/highmem.h +++ b/include/linux/highmem.h @@ -86,31 +86,16 @@ static inline void kunmap(struct page *p * be used in IRQ contexts, so in some (very limited) cases we need * it. */ - -#ifndef CONFIG_KMAP_LOCAL -void *kmap_atomic_high_prot(struct page *page, pgprot_t prot); -void kunmap_atomic_high(void *kvaddr); - static inline void *kmap_atomic_prot(struct page *page, pgprot_t p...