Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Message-ID: <841bb9a9-1cba-483f-a353-1209684f7c74@default>
Date:   Thu, 28 Feb 2019 18:35:38 -0800 (PST)
From:   Dongli Zhang <dongli.zhang@oracle.com>
To:     <xen-devel@lists.xenproject.org>, <stable@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Cc:     <boris.ostrovsky@oracle.com>, <sstabellini@kernel.org>,
        <jgross@suse.com>, <tglx@linutronix.de>, <joe.jin@oracle.com>,
        Herbert Van Den Bergh <herbert.van.den.bergh@oracle.com>,
        <sboyd@kernel.org>, <john.stultz@linaro.org>
Subject: [BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause i=
s
still in the lasted mainline kernel.

This is obviated by new feature patch set ended with b672592f0221
("sched/cputime: Remove generic asm headers").

After xen guest is up for long time, once we hotplug new vcpu, the correspo=
nding
steal usage might become 100% and the steal time from /proc/stat would incr=
ease
abnormally.

As we cannot wait for long time to reproduce the issue, here is how I repro=
duce
it on purpose by accounting a large initial steal clock for new vcpu 2 and =
3.

1. Apply the below patch to guest 4.9.160 to account large initial steal cl=
ock
for new vcpu 2 and 3:

diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index ac5f23f..3cf629e 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -85,7 +85,14 @@ u64 xen_steal_clock(int cpu)
        struct vcpu_runstate_info state;
=20
        xen_get_runstate_snapshot_cpu(&state, cpu);
-       return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline]=
;
+
+       if (cpu =3D=3D 2 || cpu =3D=3D 3)
+               return state.time[RUNSTATE_runnable]
+                      + state.time[RUNSTATE_offline]
+                      + 0x00071e87e677aa12;
+       else
+               return state.time[RUNSTATE_runnable]
+                      + state.time[RUNSTATE_offline];
 }
=20
 void xen_setup_runstate_info(int cpu)


2. Boot hvm guest with "vcpus=3D2" and "maxvcpus=3D4". By default, VM boot =
with
vcpu 0 and 1.

3. Hotplug vcpu 2 and 3 via "xl vcpu-set <domid> 4" on dom0.

In my env, the steal becomes 100% within 10s after the "xl vcpu-set" comman=
d on
dom0.

I can reproduce on kvm with similar method. However, as the initial steal c=
lock
on kvm guest is always 0, I do not think it is easy to hit this issue on kv=
m.

--------------------------------------------------------

The root cause is that the return type of jiffies_to_usecs() is 'unsigned i=
nt',
but not 'unsigned long'. As a result, the leading 32 bits are discarded.

jiffies_to_usecs() is indirectly triggered by cputime_to_nsecs() at line 26=
4.
If guest is already up for long time, the initial steal time for new vcpu m=
ight
be large and the leading 32 bits of jiffies_to_usecs() would be discarded.

As a result, the steal at line 259 is always large and the
this_rq()->prev_steal_time at line 264 is always small. The difference at l=
ine
260 is always large during each time steal_account_process_time() is involv=
ed.
Finally, the steal time in /proc/stat would increase abnormally.

252 static __always_inline cputime_t steal_account_process_time(cputime_t m=
axtime)
253 {
254 #ifdef CONFIG_PARAVIRT
255         if (static_key_false(&paravirt_steal_enabled)) {
256                 cputime_t steal_cputime;
257                 u64 steal;
258=20
259                 steal =3D paravirt_steal_clock(smp_processor_id());
260                 steal -=3D this_rq()->prev_steal_time;
261=20
262                 steal_cputime =3D min(nsecs_to_cputime(steal), maxtime)=
;
263                 account_steal_time(steal_cputime);
264                 this_rq()->prev_steal_time +=3D cputime_to_nsecs(steal_=
cputime);
265=20
266                 return steal_cputime;
267         }
268 #endif
269         return 0;
270 }

--------------------------------------------------------

I have emailed the kernel mailing list about the return type of
jiffies_to_usecs() and jiffies_to_msecs():

https://lkml.org/lkml/2019/2/26/899


So far, I have two solutions:

1. Change the return type from 'unsigned int' to 'unsigned long' as in abov=
e
link and I am afraid it would bring side effect. The return type in latest
mainline kernel is still 'unsigned int'.

2. Something like below based on stable 4.9.160:

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 734377a..9b1fc40 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -286,10 +286,11 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern unsigned long jiffies_to_usecs64(const unsigned long j);
=20
 static inline u64 jiffies_to_nsecs(const unsigned long j)
 {
-       return (u64)jiffies_to_usecs(j) * NSEC_PER_USEC;
+       return (u64)jiffies_to_usecs64(j) * NSEC_PER_USEC;
 }
=20
 extern u64 jiffies64_to_nsecs(u64 j);
diff --git a/kernel/time/time.c b/kernel/time/time.c
index a5b6d98..256c147 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -288,6 +288,27 @@ unsigned int jiffies_to_usecs(const unsigned long j)
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
=20
+unsigned long jiffies_to_usecs64(const unsigned long j)
+{
+       /*
+        * Hz usually doesn't go much further MSEC_PER_SEC.
+        * jiffies_to_usecs() and usecs_to_jiffies() depend on that.
+        */
+       BUILD_BUG_ON(HZ > USEC_PER_SEC);
+
+#if !(USEC_PER_SEC % HZ)
+       return (USEC_PER_SEC / HZ) * j;
+#else
+# if BITS_PER_LONG =3D=3D 32
+       return (HZ_TO_USEC_MUL32 * j) >> HZ_TO_USEC_SHR32;
+# else
+       return (j * HZ_TO_USEC_NUM) / HZ_TO_USEC_DEN;
+# endif
+#endif
+}
+EXPORT_SYMBOL(jiffies_to_usecs64);
+
+
 /**
  * timespec_trunc - Truncate timespec to a granularity
  * @t: Timespec

People may dislike the 2nd solution.

3. Backport patch set ended with b672592f0221 ("sched/cputime:=20
Remove generic asm headers").

This is not reasonable for stable branch as the patch set involves
lots of changes.


Would you please let me know if there is any suggestion on this issue?

Thank you very much!

Dongli Zhang