[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170124075540.171511428@linuxfoundation.org>
Date: Tue, 24 Jan 2017 08:56:08 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, Halil Pasic <pasic@...ux.vnet.ibm.com>,
Sascha Silbe <silbe@...ux.vnet.ibm.com>,
Cornelia Huck <cornelia.huck@...ibm.com>
Subject: [PATCH 4.9 128/130] tools/virtio/ringtest: fix run-on-all.sh for offline cpus
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Halil Pasic <pasic@...ux.vnet.ibm.com>
commit 21f5eda9b8671744539c8295b9df62991fffb2ce upstream.
Since ef1b144d ("tools/virtio/ringtest: fix run-on-all.sh to work
without /dev/cpu") run-on-all.sh uses seq 0 $HOST_AFFINITY as the list
of ids of the CPUs to run the command on (assuming ids of online CPUs
are consecutive and start from 0), where $HOST_AFFINITY is the highest
CPU id in the system previously determined using lscpu. This can fail
on systems with offline CPUs.
Instead let's use lscpu to determine the list of online CPUs.
Signed-off-by: Halil Pasic <pasic@...ux.vnet.ibm.com>
Fixes: ef1b144d ("tools/virtio/ringtest: fix run-on-all.sh to work without
/dev/cpu")
Reviewed-by: Sascha Silbe <silbe@...ux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@...ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
tools/virtio/ringtest/run-on-all.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/tools/virtio/ringtest/run-on-all.sh
+++ b/tools/virtio/ringtest/run-on-all.sh
@@ -1,12 +1,13 @@
#!/bin/sh
+CPUS_ONLINE=$(lscpu --online -p=cpu|grep -v -e '#')
#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=$(lscpu -p=cpu | tail -1)
+HOST_AFFINITY=$(echo "${CPUS_ONLINE}"|tail -n 1)
#run command on all cpus
-for cpu in $(seq 0 $HOST_AFFINITY)
+for cpu in $CPUS_ONLINE
do
#Don't run guest and host on same CPU
#It actually works ok if using signalling
Powered by blists - more mailing lists