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

Re: [PATCH v3 2/2] x86/mwait-idle: squash stats update when not actually entering C-state


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 1 Feb 2022 12:37:27 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=97EzxWkjILbC2ZQT0LZkqcNBN6bfE/NJI7hPdxi0FZ0=; b=iMAsvyGwHhDMrwWXmCu/PxPfUrUfNLWC4yQcObIebcvGyPj7ifzqcW8z7Rn/mhGpUwJzof/z+Eso8b2cT/UCc6vILEjXgj4gnFRZvdXqqWdvKAT9prrwAtDdCx6vFyPq+XO9g6w5c4WFmtjfJaZOlmEizI65TiJO314mYaq3ZvCRhgAW2a3UcasQH2jrHtXtvCyAUSP1m7iLFsCQPf5CB8sL2L5POdZ++Q4iNeJeIvP9WrWMs332pkxUGR8RDCGCrffRyYfF1UjFj+0n8q4aauIlNPrZo20zdywlxgo8IwsRIAd4/Nd7wh4yUvimoEUbQ/d4WGvkR59x5hRaVHNzGw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JzBpVLTNmbWGU0rwl6vohCMkjckFOdyvQlWCaesiW2XDwl3YaDG1Va3SZtSQs7HnLeqMtTjlgCGwakEGCXVpgu80OtBtMl2xURRQAiHR/xcXmHxdsrPsrXzThIgi/HFS5hcEbyqcf8Sjqq/AVM9V8Nxf4SbrLMWSbMCOK5hEbrSUFeTiIgV0uqY1vw/5X49d4Fqa0mtNxjC3jYZFaICqMry5VQPaRL7Hg+OnBTw+qHmFmZvG1oQc5F//n/+JL7AI90PaqwbUNd4hDuMElARurtKcqPZ13FoVtqCTIQkJKXPauPw+ldES6Mh65ZJ/spxwySyiPsSo+jKEkh0esnvRJw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 01 Feb 2022 11:37:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01.02.2022 12:04, Roger Pau Monné wrote:
> On Thu, Jan 27, 2022 at 04:13:47PM +0100, Jan Beulich wrote:
>> While we don't want to skip calling update_idle_stats(), arrange for it
>> to not increment the overall time spent in the state we didn't really
>> enter.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> RFC: If we wanted to also move the tracing, then I think the part ahead
>>      of the if() also would need moving. At that point we could as well
>>      move update_last_cx_stat(), too, which afaict would allow skipping
>>      update_idle_stats() on the "else" path (which therefore would go
>>      away). Yet then, with the setting of power->safe_state moved up a
>>      little (which imo it should have been anyway) the two
>>      cpu_is_haltable() invocations would only have the lapic_timer_off()
>>      invocation left in between. This would then seem to call for simply
>>      ditching the 2nd one - acpi-idle also doesn't have a 2nd instance.
> 
> It's possible for lapic_timer_off to take a non-trivial amount of time
> when virtualized, but it's likely we won't be using mwait in that
> case, so not sure it matter much to have the two cpu_is_haltable calls
> if there's just a lapic_timer_off between them.
> 
>> TBD: For the tracing I wonder if that really needs to come ahead of the
>>      local_irq_enable(). Maybe trace_exit_reason() needs to, but quite
>>      certainly TRACE_6D() doesn't.
> 
> Would be good if it could be moved after the local_irq_enable call, as
> it's not as trivial as I've expected, and will just add latency to any
> pending interrupt waiting to be serviced. FWIW, I haven't spotted a
> need to call it with interrupt disabled.

Okay, I guess I'll to the larger rework then.

>> --- a/xen/arch/x86/cpu/mwait-idle.c
>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>> @@ -854,17 +854,23 @@ static void mwait_idle(void)
>>              mwait_idle_with_hints(cx->address, MWAIT_ECX_INTERRUPT_BREAK);
>>  
>>              local_irq_disable();
>> -    }
>>  
>> -    after = alternative_call(cpuidle_get_tick);
>> +            after = alternative_call(cpuidle_get_tick);
>> +
>> +            cstate_restore_tsc();
>> +
>> +            /* Now back in C0. */
>> +            update_idle_stats(power, cx, before, after);
>> +    } else {
>> +            /* Never left C0. */
>> +            after = alternative_call(cpuidle_get_tick);
>> +            update_idle_stats(power, cx, after, after);
> 
> While adjusting this, could you also modify update_idle_stats to avoid
> increasing cx->usage if before == after (or !sleep_ticks). I don't
> think it's fine to increase the state counter if we never actually
> entered it.

I did consider it but then decided against. Even leaving this aspect
aside the counter only counts _attempts_ to enter a certain state;
the CPU may find reasons to never actually enter it. And what we have
when before == after is still an attempt, albeit an unsuccessful one.

Jan




 


Rackspace

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