From: Ruslan <ruslichenko.r@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: dfaggioli@suse.com, jgross@suse.com, gwd@xenproject.org,
artem_mygaiev@epam.com, Ruslan_Ruslichenko@epam.com,
xen-devel@lists.xenproject.org
Subject: [RESEND] Re: [PATCH] xen/sched: refactor urgent count update
Date: Wed, 30 Sep 2026 12:36:11 +0200 [thread overview]
Message-ID: <7bfea588-da85-4edc-a8e9-5f2379c65d0f@gmail.com> (raw)
In-Reply-To: <1753bd8f-effd-40c4-a3b0-1e61ec8f7474@suse.com>
Resending since Google web client mangled the formatting of previous mail.
On 9/29/26 17:35, Jan Beulich wrote:
> On 25.09.2026 23:28, Ruslan Ruslichenko wrote:
>> From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>>
>> With current implementation whenever vCPU blocks on
>> waiting for event channel via SCHEDOP_poll hypercall,
>> scheduler sets 'is_urgent' flag. The flag is cleared
>> on vCPU runstate change, if it is no longer in
>> 'VPF_blocked' state or its vcpu_id is not in poll_mask.
>>
>> However, the only way for vCPU runstate to change in
>> polled state is when it's going to wakeup.
>>
>> Thus when 'is_urgent' is set, inner condition will always be:
>>
>> if ( unlikely(v->is_urgent) )
>> {
>> if ( !(v->pause_flags & VPF_blocked) || // Always True
>> !test_bit(v->vcpu_id, v->domain->poll_mask) ) // Never evaluated
>
> Maybe this invariant indeed applies, but then there must be more to it.
> Simply from taking the "else" branch here
>
> if ( unlikely(v->pause_flags & VPF_blocked) &&
> unlikely(test_bit(v->vcpu_id, v->domain->poll_mask)) )
> {
> v->is_urgent = 1;
> atomic_inc(&per_cpu(sched_urgent_count, v->processor));
> }
>
> clearly immediately afterwards the invariant you name does not hold.
>
I should have described the preconditions for this. vcpu_urgent_count_update()
only called by vcpu_runstate_change(), which returns early if
'v->runstate.state == new_state'.
v->is_urgent set means vCPU is in RUNSTATE_blocked, so the only change
from RUNSTATE_blocked
is to RUNSTATE_runnable or RUNSTATE_offline, and both require
_VPF_blocked clear.
Also vcpu_unblock() clears _VPF_blocked first and it is used by wakeup
sources: event_channel, irqs and poll_timer itself.
I will refine this in the commit message.
>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -241,26 +241,22 @@ static inline void trace_continue_running(const struct vcpu *v)
>>
>> static inline void vcpu_urgent_count_update(struct vcpu *v)
>> {
>> + bool cur_urgent;
>> +
>> if ( is_idle_vcpu(v) )
>> return;
>>
>> - if ( unlikely(v->is_urgent) )
>> - {
>> - if ( !(v->pause_flags & VPF_blocked) ||
>> - !test_bit(v->vcpu_id, v->domain->poll_mask) )
>> - {
>> - v->is_urgent = 0;
>> - atomic_dec(&per_cpu(sched_urgent_count, v->processor));
>> - }
>> - }
>> - else
>> + cur_urgent = (v->pause_flags & VPF_blocked) &&
>> + test_bit(v->vcpu_id, v->domain->poll_mask);
>> +
>> + if ( unlikely(v->is_urgent != cur_urgent) )
>> {
>> - if ( unlikely(v->pause_flags & VPF_blocked) &&
>> - unlikely(test_bit(v->vcpu_id, v->domain->poll_mask)) )
>> - {
>> - v->is_urgent = 1;
>> + v->is_urgent = cur_urgent;
>> +
>> + if ( cur_urgent )
>> atomic_inc(&per_cpu(sched_urgent_count, v->processor));
>> - }
>> + else
>> + atomic_dec(&per_cpu(sched_urgent_count, v->processor));
>
> Assuming the transformation is valid to make (scheduler maintainers will
> need to judge), may I suggest to fold these two into a single atomic_add(),
> passing in either +1 or -1?
>
This looks like a good improvement, thanks. I will update for v2.
--
Best Regards,
Ruslan
> Jan
prev parent reply other threads:[~2026-09-30 10:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 21:28 [PATCH] xen/sched: refactor urgent count update Ruslan Ruslichenko
2026-09-29 15:35 ` Jan Beulich
2026-09-30 10:36 ` Ruslan [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=7bfea588-da85-4edc-a8e9-5f2379c65d0f@gmail.com \
--to=ruslichenko.r@gmail.com \
--cc=Ruslan_Ruslichenko@epam.com \
--cc=artem_mygaiev@epam.com \
--cc=dfaggioli@suse.com \
--cc=gwd@xenproject.org \
--cc=jbeulich@suse.com \
--cc=jgross@suse.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.