Re: [PATCH v3] virtio-net: Add initial MTU advice feature

2016-06-06 Thread David Miller
From: Aaron Conole 
Date: Fri,  3 Jun 2016 16:57:12 -0400

> This commit adds the feature bit and associated mtu device entry for the
> virtio network device.  When a virtio device comes up, it checks the
> feature bit for the VIRTIO_NET_F_MTU feature.  If such feature bit is
> enabled, the driver will read the advised MTU and use it as the initial
> value.
> 
> Signed-off-by: Aaron Conole 

Applied, thanks.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH 10/20] drm: rockchip: Rely on the default ->best_encoder() behavior

2016-06-06 Thread Mark yao

On 2016年06月02日 22:31, Boris Brezillon wrote:

All outputss have a 1:1 relationship between connectors and encoders
and the driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementations  and let the core call
drm_atomic_helper_best_encoder() for us.


Good, All connectors and encoders is 1:1 relationship on rockchip 
outputs, so


Acked-by: Mark Yao 



Signed-off-by: Boris Brezillon 
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 -
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 9 -
  2 files changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index dedc65b..ca22e5e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -964,18 +964,9 @@ static enum drm_mode_status dw_mipi_dsi_mode_valid(
return mode_status;
  }
  
-static struct drm_encoder *dw_mipi_dsi_connector_best_encoder(

-   struct drm_connector *connector)
-{
-   struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
-   return >encoder;
-}
-
  static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = 
{
.get_modes = dw_mipi_dsi_connector_get_modes,
.mode_valid = dw_mipi_dsi_mode_valid,
-   .best_encoder = dw_mipi_dsi_connector_best_encoder,
  };
  
  static enum drm_connector_status

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f8b4feb..006260d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -579,14 +579,6 @@ inno_hdmi_connector_mode_valid(struct drm_connector 
*connector,
return MODE_OK;
  }
  
-static struct drm_encoder *

-inno_hdmi_connector_best_encoder(struct drm_connector *connector)
-{
-   struct inno_hdmi *hdmi = to_inno_hdmi(connector);
-
-   return >encoder;
-}
-
  static int
  inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
   uint32_t maxX, uint32_t maxY)
@@ -613,7 +605,6 @@ static struct drm_connector_funcs inno_hdmi_connector_funcs 
= {
  static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
.get_modes = inno_hdmi_connector_get_modes,
.mode_valid = inno_hdmi_connector_mode_valid,
-   .best_encoder = inno_hdmi_connector_best_encoder,
  };
  
  static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)



--
Mark Yao


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Intel-gfx] [PATCH 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

2016-06-06 Thread Chris Wilson
On Thu, Jun 02, 2016 at 11:57:02PM +0200, Daniel Vetter wrote:
> drm_encoder_find is an idr lookup. That should be plenty fast,
> especially for modeset code. Usually what's too expensive even for
> modeset code is linear list walks. But Chris just submitted patches to
> convert most of them into simple lookups.

For the idr_find, I'm tempted to replace the mutex with a rwlock. It
helps pathological cases, but in reality there are more crucial
locks around the hw that limit concurrency. ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

2016-06-06 Thread Benjamin Herrenschmidt
On Mon, 2016-06-06 at 17:59 +0200, Peter Zijlstra wrote:
> On Fri, Jun 03, 2016 at 02:33:47PM +1000, Benjamin Herrenschmidt wrote:
> > 
> >  - For the above, can you show (or describe) where the qspinlock
> >    improves things compared to our current locks.
> So currently PPC has a fairly straight forward test-and-set spinlock
> IIRC. You have this because LPAR/virt muck and lock holder preemption
> issues etc..
> qspinlock is 1) a fair lock (like ticket locks) and 2) provides
> out-of-word spinning, reducing cacheline pressure.

Thanks Peter. I think I understand the theory, but I'd like see it
translate into real numbers.

> Esp. on multi-socket x86 we saw the out-of-word spinning being a big win
> over our ticket locks.
> 
> And fairness, brought to us by the ticket locks a long time ago,
> eliminated starvation issues we had, where a spinner local to the holder
> would 'always' win from a spinner further away. So under heavy enough
> local contention, the spinners on 'remote' CPUs would 'never' get to own
> the lock.

I think our HW has tweaks to avoid that from happening with the simple
locks in the underlying ll/sc implementation. In any case, what I'm
asking is actual tests to verify it works as expected for us.

> pv-qspinlock tries to preserve the fairness while allowing limited lock
> stealing and explicitly managing which vcpus to wake.

Right.
> > 
> > While there's
> >    theory and to some extent practice on x86, it would be nice to
> >    validate the effects on POWER.
> Right; so that will have to be from benchmarks which I cannot help you
> with ;-)

Precisely :-) This is what I was asking for ;-)

Cheers,
Ben.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

2016-06-06 Thread Peter Zijlstra
On Fri, Jun 03, 2016 at 02:33:47PM +1000, Benjamin Herrenschmidt wrote:
>  - For the above, can you show (or describe) where the qspinlock
>    improves things compared to our current locks.

So currently PPC has a fairly straight forward test-and-set spinlock
IIRC. You have this because LPAR/virt muck and lock holder preemption
issues etc..

qspinlock is 1) a fair lock (like ticket locks) and 2) provides
out-of-word spinning, reducing cacheline pressure.

Esp. on multi-socket x86 we saw the out-of-word spinning being a big win
over our ticket locks.

And fairness, brought to us by the ticket locks a long time ago,
eliminated starvation issues we had, where a spinner local to the holder
would 'always' win from a spinner further away. So under heavy enough
local contention, the spinners on 'remote' CPUs would 'never' get to own
the lock.

pv-qspinlock tries to preserve the fairness while allowing limited lock
stealing and explicitly managing which vcpus to wake.

>   While there's
>    theory and to some extent practice on x86, it would be nice to
>    validate the effects on POWER.

Right; so that will have to be from benchmarks which I cannot help you
with ;-)
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH RESEND 06/14] drm/virtio: use drm_crtc_send_vblank_event()

2016-06-06 Thread Gustavo Padovan
From: Gustavo Padovan 

Replace the legacy drm_send_vblank_event() with the new helper function.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index d4305da..ba5e11b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -156,7 +156,7 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
 
if (event) {
spin_lock_irqsave(>dev->event_lock, irqflags);
-   drm_send_vblank_event(crtc->dev, -1, event);
+   drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(>dev->event_lock, irqflags);
}
 
-- 
2.5.5

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH v3] tools/virtio/ringtest: fix run-on-all.sh to work without /dev/cpu

2016-06-06 Thread Michael S. Tsirkin
It's queued in my tree and will be merged shortly.
Thanks!

On Mon, Jun 06, 2016 at 09:55:59AM +0300, Mike Rapoport wrote:
> Ping?
> 
> On Tue, May 24, 2016 at 03:41:33PM +0300, Mike Rapoport wrote:
> > Michael,
> > 
> > Any updates on this?
> > 
> > On Wed, May 04, 2016 at 01:15:50PM +0300, Mike Rapoport wrote:
> > > /dev/cpu is only available on x86 with certain modules (e.g. msr) enabled.
> > > Using lscpu to get processors count is more portable.
> > > 
> > > Signed-off-by: Mike Rapoport 
> > > ---
> > > v3: simplify by using lscpu -p=cpu 
> > > v2: use lspcu instead of /proc/cpuinfo as per Cornelia's suggestion
> > > 
> > >  tools/virtio/ringtest/run-on-all.sh | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tools/virtio/ringtest/run-on-all.sh 
> > > b/tools/virtio/ringtest/run-on-all.sh
> > > index 52b0f71..2e69ca8 100755
> > > --- a/tools/virtio/ringtest/run-on-all.sh
> > > +++ b/tools/virtio/ringtest/run-on-all.sh
> > > @@ -3,10 +3,10 @@
> > >  #use last CPU for host. Why not the first?
> > >  #many devices tend to use cpu0 by default so
> > >  #it tends to be busier
> > > -HOST_AFFINITY=$(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n|tail -1)
> > > +HOST_AFFINITY=$(lscpu -p=cpu | tail -1)
> > > 
> > >  #run command on all cpus
> > > -for cpu in $(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n);
> > > +for cpu in $(seq 0 $HOST_AFFINITY)
> > >  do
> > >   #Don't run guest and host on same CPU
> > >   #It actually works ok if using signalling
> > > -- 
> > > 1.9.1
> > > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH] tools/virtio/ringtest: add usage example to README

2016-06-06 Thread Mike Rapoport
Ping?

On Tue, May 24, 2016 at 03:41:04PM +0300, Mike Rapoport wrote:
> Michael,
> 
> Any updates on this?
> 
> On Wed, May 04, 2016 at 09:12:55AM +0300, Mike Rapoport wrote:
> > Having typical usage example in the README file is more convinient than in
> > the git history...
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> >  tools/virtio/ringtest/README | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/tools/virtio/ringtest/README b/tools/virtio/ringtest/README
> > index 34e94c4..d83707a 100644
> > --- a/tools/virtio/ringtest/README
> > +++ b/tools/virtio/ringtest/README
> > @@ -1,2 +1,6 @@
> >  Partial implementation of various ring layouts, useful to tune virtio 
> > design.
> >  Uses shared memory heavily.
> > +
> > +Typical use:
> > +
> > +# sh run-on-all.sh perf stat -r 10 --log-fd 1 -- ./ring
> > -- 
> > 1.9.1
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH v3] tools/virtio/ringtest: fix run-on-all.sh to work without /dev/cpu

2016-06-06 Thread Mike Rapoport
Ping?

On Tue, May 24, 2016 at 03:41:33PM +0300, Mike Rapoport wrote:
> Michael,
> 
> Any updates on this?
> 
> On Wed, May 04, 2016 at 01:15:50PM +0300, Mike Rapoport wrote:
> > /dev/cpu is only available on x86 with certain modules (e.g. msr) enabled.
> > Using lscpu to get processors count is more portable.
> > 
> > Signed-off-by: Mike Rapoport 
> > ---
> > v3: simplify by using lscpu -p=cpu 
> > v2: use lspcu instead of /proc/cpuinfo as per Cornelia's suggestion
> > 
> >  tools/virtio/ringtest/run-on-all.sh | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/virtio/ringtest/run-on-all.sh 
> > b/tools/virtio/ringtest/run-on-all.sh
> > index 52b0f71..2e69ca8 100755
> > --- a/tools/virtio/ringtest/run-on-all.sh
> > +++ b/tools/virtio/ringtest/run-on-all.sh
> > @@ -3,10 +3,10 @@
> >  #use last CPU for host. Why not the first?
> >  #many devices tend to use cpu0 by default so
> >  #it tends to be busier
> > -HOST_AFFINITY=$(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n|tail -1)
> > +HOST_AFFINITY=$(lscpu -p=cpu | tail -1)
> > 
> >  #run command on all cpus
> > -for cpu in $(cd /dev/cpu; ls|grep -v '[a-z]'|sort -n);
> > +for cpu in $(seq 0 $HOST_AFFINITY)
> >  do
> > #Don't run guest and host on same CPU
> > #It actually works ok if using signalling
> > -- 
> > 1.9.1
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization