search for: zone_dma

On Sun, 12 May 2019, Halil Pasic wrote: > I've also got code that deals with AIRQ_IV_CACHELINE by turning the > kmem_cache into a dma_pool. > > Cornelia, Sebastian which approach do you prefer: > 1) get rid of cio_dma_pool and AIRQ_IV_CACHELINE, and waste a page per > vector, or > 2) go with the approach taken by the patch below? We only have a couple of users for

On Sun, 12 May 2019, Halil Pasic wrote: > I've also got code that deals with AIRQ_IV_CACHELINE by turning the > kmem_cache into a dma_pool. > > Cornelia, Sebastian which approach do you prefer: > 1) get rid of cio_dma_pool and AIRQ_IV_CACHELINE, and waste a page per > vector, or > 2) go with the approach taken by the patch below? We only have a couple of users for

...ENOMEM in do_get_write_access, retrying. >> Aug 31 04:16:05 moss kernel: journal_write_metadata_buffer: ENOMEM >> at get_unused_buffer_head, trying again. >> >> anyone seen this? > > Not an rsync problem. This is a kernel issue. > > You seem to be out of ZONE_DMA memory. I don't know whether > you should be reporting this to RH or Veritas or IBM but > when you do be sure to send them /proc/slabinfo from the > moment of error. > > One thing you might try is booting with mem=900M Running > with more than 900M < n < 1G memory on...

At OLS we had a couple of "Xen Mini Summit" sessions. Although there weren''t any formal minutes, here''s a rough summary of what we discussed/concluded. Status as of 24 July 2005 ========================= Summary: We have a couple of annoying bugs, but things are coming together nicely. x86_32p (PAE 16GB) and x86_64 ports are close to being feature complete with

...> 1..nr_cpu (for the summary bit vector) > > > > I guess this is the same. > > > > > The options are: > > * page allocations for everything > > Worst case we need 20 + #max_pci_dev pages. At the moment we allocate > from ZONE_DMA (!) and waste a lot. > > > * dma_pool for AIRQ_IV_CACHELINE ,gen_pool for others > > I prefer this. Explanation follows. > > > * dma_pool for everything > > > > Less waste by factor factor 16. > > > I think we should do option 3 and use a dma_pool...

On Wed, 29 May 2019 14:26:56 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > From: Halil Pasic <pasic at linux.ibm.com> > > Before virtio-ccw could get away with not using DMA API for the pieces of > memory it does ccw I/O with. With protected virtualization this has to > change, since the hypervisor needs to read and sometimes also write these > pieces of

On Wed, 29 May 2019 14:26:56 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > From: Halil Pasic <pasic at linux.ibm.com> > > Before virtio-ccw could get away with not using DMA API for the pieces of > memory it does ccw I/O with. With protected virtualization this has to > change, since the hypervisor needs to read and sometimes also write these > pieces of

...PU directed IRQs: 2K (for the per-CPU bit vectors) > 1..nr_cpu (for the summary bit vector) > I guess this is the same. > > The options are: > * page allocations for everything Worst case we need 20 + #max_pci_dev pages. At the moment we allocate from ZONE_DMA (!) and waste a lot. > * dma_pool for AIRQ_IV_CACHELINE ,gen_pool for others I prefer this. Explanation follows. > * dma_pool for everything > Less waste by factor factor 16. > I think we should do option 3 and use a dma_pool with cachesize > alignment for everything (as a prer...

I have seen this error in many postings, but the solutions seem not to apply in this case. This error happens during a small file transfer (gif image) and after 75% of a 165G rsync job (the building file list portion is complete.) Most solutions I saw were related to not having enough RAM or running out of disk space. Check out the machine specs below the error. rsync: writefd_unbuffered

...__vc_dma_alloc() back then is because I had no clarity what do we want to do there. If you take a look the body of __vc_dma_alloc() changed quite a lot, while I the usage not so much. Regarding why is the first argument a pointer struct virtio_device, the idea was probably to keep the needs to be ZONE_DMA and can use the full 64 bit address space separate. But I abandoned the ideal. Also vc_dma_alloc_struct() started out more elaborate (I used to manage a dma_addr_t as well -- see RFC). I'm not quite sure what is your problem with the these. As far as I understand, this is another of those mat...

...ble memory because we can't tell > (with the current common DMA code) hey but this piece of DMA mem you > are abot to allocate for me must be 31 bit addressable (using GFP_DMA > as we usually do). > > So, as described in the commit message, the vring stuff being forced > into ZONE_DMA is an unfortunate consequence of this all. Yeah. I hope 31 bits are enough for that as well. > > A side note: making the subchannel device 'own' the DMA stuff of a ccw > device (something that was discussed in the RFC thread) is tricky > because the ccw device may outlive the...

...ble memory because we can't tell > (with the current common DMA code) hey but this piece of DMA mem you > are abot to allocate for me must be 31 bit addressable (using GFP_DMA > as we usually do). > > So, as described in the commit message, the vring stuff being forced > into ZONE_DMA is an unfortunate consequence of this all. Yeah. I hope 31 bits are enough for that as well. > > A side note: making the subchannel device 'own' the DMA stuff of a ccw > device (something that was discussed in the RFC thread) is tricky > because the ccw device may outlive the...

...> because I had no clarity what do we want to do there. If you take a look > the body of __vc_dma_alloc() changed quite a lot, while I the usage not > so much. > > Regarding why is the first argument a pointer struct virtio_device, the > idea was probably to keep the needs to be ZONE_DMA and can use the full > 64 bit address space separate. But I abandoned the ideal. > > Also vc_dma_alloc_struct() started out more elaborate (I used to manage > a dma_addr_t as well -- see RFC). Understood, history is often important :) > > I'm not quite sure what is your pr...

...gt; #include <asm/dma.h> -#include <asm/kmap_types.h> #include <asm/maar.h> #include <asm/mmu_context.h> #include <asm/sections.h> @@ -402,9 +401,6 @@ void __init paging_init(void) pagetable_init(); -#ifdef CONFIG_HIGHMEM - kmap_init(); -#endif #ifdef CONFIG_ZONE_DMA max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN; #endif

...t > > tell (with the current common DMA code) hey but this piece of DMA > > mem you are abot to allocate for me must be 31 bit addressable > > (using GFP_DMA as we usually do). > > > > So, as described in the commit message, the vring stuff being forced > > into ZONE_DMA is an unfortunate consequence of this all. > > Yeah. I hope 31 bits are enough for that as well. > > > > > A side note: making the subchannel device 'own' the DMA stuff of a > > ccw device (something that was discussed in the RFC thread) is tricky > > bec...

...restricted to 31 bit addressable memory because we can't tell (with the current common DMA code) hey but this piece of DMA mem you are abot to allocate for me must be 31 bit addressable (using GFP_DMA as we usually do). So, as described in the commit message, the vring stuff being forced into ZONE_DMA is an unfortunate consequence of this all. A side note: making the subchannel device 'own' the DMA stuff of a ccw device (something that was discussed in the RFC thread) is tricky because the ccw device may outlive the subchannel (all that orphan stuff). So the answer is: it is technicall...

On Fri, 26 Apr 2019 20:32:41 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > This patch addresses the most basic stuff (mostly what is required for > virtio-ccw), and does take care of QDIO or any devices. "does not take care of QDIO",

On Fri, 26 Apr 2019 20:32:41 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > This patch addresses the most basic stuff (mostly what is required for > virtio-ccw), and does take care of QDIO or any devices. "does not take care of QDIO",

..._ATLAS7 select HAVE_ARM_SCU if SMP select HAVE_SMP help - Support for CSR SiRFSoC ARM Cortex A7 Platform + Support for CSR SiRFSoC ARM Cortex A7 Platform config ARCH_PRIMA2 bool "CSR SiRFSoC PRIMA2 ARM Cortex A9 Platform" @@ -41,7 +41,7 @@ config ARCH_PRIMA2 select ZONE_DMA select PRIMA2_TIMER help - Support for CSR SiRFSoC ARM Cortex A9 Platform + Support for CSR SiRFSoC ARM Cortex A9 Platform config SIRF_IRQ bool diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 686f0bbde998..95db290637aa 100644 --- a/arch/arm/mach-...

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all