search for: airq_iv_cacheline

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 airq_iv...

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 airq_iv...

On Thu, 23 May 2019 18:22:06 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > From: Halil Pasic <pasic at linux.ibm.com> > > The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let > us use it! We actually wanted the vector to span a cacheline all along. > > Signed-off-by: Halil Pasic <pasic at linux.ibm.com> > --- > drivers/s390/virtio/virtio_ccw.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-)...

...I did a quick check. virtio_ccw_init() should be OK, because we don't > register the driver if allocation fails, so the thing is going to end > up dysfunctional as expected. > > If however cio_dma_pool_init() fails, then we end up with the same > problem with airqs, just on the !AIRQ_IV_CACHELINE code path. It can be > fixed analogously: make cio_dma_zalloc() fail all allocation if > cio_dma_pool_init() failed before. Ok, makes sense. > > The rest should be OK. > > > > > > > I would prefer having a separate discussion on eventually changing > > &g...

...I did a quick check. virtio_ccw_init() should be OK, because we don't > register the driver if allocation fails, so the thing is going to end > up dysfunctional as expected. > > If however cio_dma_pool_init() fails, then we end up with the same > problem with airqs, just on the !AIRQ_IV_CACHELINE code path. It can be > fixed analogously: make cio_dma_zalloc() fail all allocation if > cio_dma_pool_init() failed before. Ok, makes sense. > > The rest should be OK. > > > > > > > I would prefer having a separate discussion on eventually changing > > &g...

On Tue, 11 Jun 2019 16:27:21 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On Tue, 11 Jun 2019 12:17:21 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Thu, 6 Jun 2019 13:51:23 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > > > > > Protected virtualization guests have to use shared pages for airq > > >

On Tue, 11 Jun 2019 16:27:21 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On Tue, 11 Jun 2019 12:17:21 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Thu, 6 Jun 2019 13:51:23 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > > > > > Protected virtualization guests have to use shared pages for airq > > >

...* @bits: number of bits in the interrupt vector @@ -132,17 +139,19 @@ struct airq_iv *airq_iv_create(unsigned long bits, unsigned long flags) goto out; iv->bits = bits; iv->flags = flags; - size = BITS_TO_LONGS(bits) * sizeof(unsigned long); + size = iv_size(bits); if (flags & AIRQ_IV_CACHELINE) { - if ((cache_line_size() * BITS_PER_BYTE) < bits) + if ((cache_line_size() * BITS_PER_BYTE) < bits + || !airq_iv_cache) goto out_free; - iv->vector = kmem_cache_zalloc(airq_iv_cache, GFP_KERNEL); + iv->vector = dma_pool_zalloc(airq_iv_cache, GFP_KERNEL, + &i...

On Thu, 16 May 2019 15:59:22 +0200 (CEST) Sebastian Ott <sebott at linux.ibm.com> wrote: > 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...

...g? > Good question! I did a quick check. virtio_ccw_init() should be OK, because we don't register the driver if allocation fails, so the thing is going to end up dysfunctional as expected. If however cio_dma_pool_init() fails, then we end up with the same problem with airqs, just on the !AIRQ_IV_CACHELINE code path. It can be fixed analogously: make cio_dma_zalloc() fail all allocation if cio_dma_pool_init() failed before. The rest should be OK. > > > > I would prefer having a separate discussion on eventually changing > > the behavior (e.g. fail css initialization). > >...

On Fri, 10 May 2019 00:11:12 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On Thu, 9 May 2019 12:11:06 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Wed, 8 May 2019 23:22:10 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > > > > > On Wed, 8 May 2019 15:18:10 +0200 (CEST) > > > Sebastian Ott <sebott

On Fri, 10 May 2019 00:11:12 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On Thu, 9 May 2019 12:11:06 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Wed, 8 May 2019 23:22:10 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > > > > > On Wed, 8 May 2019 15:18:10 +0200 (CEST) > > > Sebastian Ott <sebott

...* @bits: number of bits in the interrupt vector @@ -132,17 +139,18 @@ struct airq_iv *airq_iv_create(unsigned long bits, unsigned long flags) goto out; iv->bits = bits; iv->flags = flags; - size = BITS_TO_LONGS(bits) * sizeof(unsigned long); + size = iv_size(bits); if (flags & AIRQ_IV_CACHELINE) { if ((cache_line_size() * BITS_PER_BYTE) < bits) goto out_free; - iv->vector = kmem_cache_zalloc(airq_iv_cache, GFP_KERNEL); + iv->vector = dma_pool_zalloc(airq_iv_cache, GFP_KERNEL, + &iv->vector_dma); if (!iv->vector) goto out_free; } else { - iv...

...* @bits: number of bits in the interrupt vector @@ -132,17 +139,18 @@ struct airq_iv *airq_iv_create(unsigned long bits, unsigned long flags) goto out; iv->bits = bits; iv->flags = flags; - size = BITS_TO_LONGS(bits) * sizeof(unsigned long); + size = iv_size(bits); if (flags & AIRQ_IV_CACHELINE) { if ((cache_line_size() * BITS_PER_BYTE) < bits) goto out_free; - iv->vector = kmem_cache_zalloc(airq_iv_cache, GFP_KERNEL); + iv->vector = dma_pool_zalloc(airq_iv_cache, GFP_KERNEL, + &iv->vector_dma); if (!iv->vector) goto out_free; } else { - iv...

...* @bits: number of bits in the interrupt vector @@ -132,17 +139,18 @@ struct airq_iv *airq_iv_create(unsigned long bits, unsigned long flags) goto out; iv->bits = bits; iv->flags = flags; - size = BITS_TO_LONGS(bits) * sizeof(unsigned long); + size = iv_size(bits); if (flags & AIRQ_IV_CACHELINE) { if ((cache_line_size() * BITS_PER_BYTE) < bits) goto out_free; - iv->vector = kmem_cache_zalloc(airq_iv_cache, GFP_KERNEL); + iv->vector = dma_pool_zalloc(airq_iv_cache, GFP_KERNEL, + &iv->vector_dma); if (!iv->vector) goto out_free; } else { - iv...

From: Halil Pasic <pasic at linux.ibm.com> The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let us use it! We actually wanted the vector to span a cacheline all along. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> --- drivers/s390/virtio/virtio_ccw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/s390/vir...

From: Halil Pasic <pasic at linux.ibm.com> The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let us use it! We actually wanted the vector to span a cacheline all along. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Signed-off-by: Michael Mueller <mimu at linux.ibm.com> --- drivers/s390/virtio/virtio_ccw.c | 3 ++- 1 file changed,...

The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let us use it! We actually wanted the vector to span a cacheline all along. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger at de.ibm.com> Reviewed-by: Cornelia Huck <cohuck at redhat.com>...

...ing for more than a page would just fail, but I addressed > that in the patch I've hacked up on top of the series, and I'm going to > paste below. While at it I addressed some other issues as well. Hm, which "other issues"? > > I've also got code that deals with AIRQ_IV_CACHELINE by turning the > kmem_cache into a dma_pool. Isn't that percolating to other airq users again? Or maybe I just don't understand what you're proposing here... > > Cornelia, Sebastian which approach do you prefer: > 1) get rid of cio_dma_pool and AIRQ_IV_CACHELINE, and wast...

...ing for more than a page would just fail, but I addressed > that in the patch I've hacked up on top of the series, and I'm going to > paste below. While at it I addressed some other issues as well. Hm, which "other issues"? > > I've also got code that deals with AIRQ_IV_CACHELINE by turning the > kmem_cache into a dma_pool. Isn't that percolating to other airq users again? Or maybe I just don't understand what you're proposing here... > > Cornelia, Sebastian which approach do you prefer: > 1) get rid of cio_dma_pool and AIRQ_IV_CACHELINE, and wast...