From: Simon Gaiser <simon@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>
Cc: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Subject: Re: RFC: disable HPET legacy mode after timer check
Date: Mon, 17 Apr 2023 14:10:35 +0200 [thread overview]
Message-ID: <87a2e249-4dd6-ddd7-680b-dfc21e57e638@invisiblethingslab.com> (raw)
In-Reply-To: <0ac3fce6-dcd2-4521-6207-ede4d90e656b@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1884 bytes --]
Andrew Cooper:
[...]
>> It reaches low power states only for a fraction of the suspend to idle
>> time, so something still makes the CPU/chipset think it should leave the
>> low power mode, but that's another topic.
>
> Do you have any further info here? There are a range of possibilities,
> from excess timers in Xen (e.g. PV guests default to a 100Hz timer even
> though no guests actually want it AFAICT), or the 1s TSC rendezvous
> (which isn't actually needed on modern systems), all the way to the
> platform devices not entering d3hot.
So in the meantime I got some progress here.
What helps a lot is setting cpufreq to powersave before going to s2idle.
With that I get residency of about 88 % (everything is still tested with
only dom0 running). Not yet the > 99 % that a native Linux manages, but
much better than before (<< 50 %).
While, based on your and Marek's feedback, I was already looking at
active timers, I first ignored the cpufreq dbs timer since the idle
driver suspend it and I assumed it was active because I wake things up
when triggering the debug key. But turns out disabling the ondemand
governor has a big effect. But not sure if it's the timer itself or some
other part of it.
I tried to disable the time calibration timer. While eyeballing on the
power meter I first thought it brings some improvement there's no
difference according to the residency counters (will need to improve my
power measurement setup).
Other timers I see active:
common/sched/core.c#vcpu_singleshot_timer_fn:
If I understand correctly those are configure by the domain (so dom0
here). So Linux should do this right. But I will have to have a closer
look.
arch/x86/cpu/mcheck/non-fatal.c#mce_work_fn:
Triggers only seldom (something >> 1 s), so unlikely. But will try
disabling.
arch/x86/time.c#plt_overflow:
Dito.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-04-17 12:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 10:30 RFC: disable HPET legacy mode after timer check Simon Gaiser
2023-04-11 11:20 ` Andrew Cooper
2023-04-12 11:25 ` Roger Pau Monné
2023-04-17 8:49 ` Jan Beulich
2023-04-17 10:26 ` Roger Pau Monné
2023-04-17 12:10 ` Simon Gaiser [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a2e249-4dd6-ddd7-680b-dfc21e57e638@invisiblethingslab.com \
--to=simon@invisiblethingslab.com \
--cc=andrew.cooper3@citrix.com \
--cc=marmarek@invisiblethingslab.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.