[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ryzen 4000 (Mobile) Softlocks/Micro-stutters



Hi,

Interesting situation (so to speak... :-O)

On Thu, 2020-10-15 at 11:20 +0200, Jan Beulich wrote:
> On 15.10.2020 11:14, Dylanger Daly wrote:
> > Indeed this is for dom0, I only recently tried limiting a domU to 1
> > core and observed absolutely no softlocks, UI animations are smooth
> > as butter with 1 core only.
> > 
> > Indeed I believe this is a CPU Scheduling issue, I've tried both
> > the older credit and RTDS however both don't boot correctly.
> 
> This wants reporting (with sufficient data, i.e. at least a serial
> log)
> as separate issues.
> 
Indeed.

So, just to be sure I am understanding the symptoms correctly: here you
say that Credit (and RTDS) "don't boot correctly". In another mail, I
think you said that Credit boots, but is unusable due to lag and
lockups... Which is which?

Also, since this looks like it is SMT related, is Credit bootable
and/or usable with SMT off? And with SMT on?

> > The number of cores on this CPU is 8, 16 threads however Qubes by
> > default disables SMT, sched_credit2_max_cpus_runqueue is 16 by
> > default, I've tried testing with setting this to 7 or 8 however
> > it'll either not boot, or nothing will change.
> 
> Failure to boot, unless with insane command line options, should
> always
> be reported to it can be fixed.
> 
Yeah and facts are:

1) no value of the sched_credit2_max_cpus_runqueue option should 
   prevent the system from booting. If it does, it's definitely a bug.

   It'd be "wonderful" to see _how_ it does that, by seeing the 
   stacktrace (preferrably of a debug build), if there is one. Or, if 
   the system locks, e.g., knowing whether it is responsive at least 
   to debug keys (and, if yest, how the output of the 'r' debug key 
   looks like)

2) A suboptimal value of sched_credit2_max_cpus_runqueue may indeed be 
   associated with performance issues, including lags and lookups. 
   *BUT* that usually happens on large boxes, with like 128 or 256 
   CPUs. In your case, having either 8 or 16 CPUs in the same Credit2
   runqueue (or in two runqueue if you leave SMT on and use 8 as the 
   value of that param) should work just fine. And, for sure, it 
   shouldn't hang.

So, again, I'm not doubting it's happening, but I can't immediately
think of a root cause, especially without seeing more info.

In absence of that, I only have more questions. :-/ E.g., how are you
enabling and disabling SMT, via the command line parameter, or via
BIOS?

Also, can you perhaps try either upstream 4.14 Xen (from sources, I
mean) or the packages for a distro different than QubesOS (perhaps
installing such distro, temporarily, in an external HD or whatever).

Note that I by no means am trying to blame Qubes or anything else in
particular... I'm just trying to understand.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.