Skip to contentSkip to conversation

Removal of redundant check

PATCH In review Praveen Kumar 3 participants 3 messages Dec 14, 2016 – Dec 15, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Removal of redundant check

The patch gets rid of a redundant check in csched_vcpu_acct which adds more code clarity and performance. This patch also adds an ASSERT to the same effect, in order to make assumption ( i.e., no calling this on idle vcpus) even more clear and as a guard for future mis-use.

xen/common/sched_credit.c +0 -0
index fc3a321..dfe8545 100644
@@ -941,6 +941,7 @@ csched_vcpu_acct(struct csched_private *prv,

unsigned int cpu)

     ASSERT( current->processor == cpu );
     ASSERT( svc->sdom != NULL );
+    ASSERT( !is_idle_vcpu(svc->vcpu) );

     /*
      * If this VCPU's priority was boosted when it last awoke, reset it.
@@ -957,8 +958,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu)
     /*
      * Update credits
      */
-    if ( !is_idle_vcpu(svc->vcpu) )
-        burn_credits(svc, NOW());
+    burn_credits(svc, NOW());

     /*
      * Put this VCPU and domain back on the active list if it was

The patch gets rid of a redundant check in csched_vcpu_acct which adds more code clarity and performance. This patch also adds an ASSERT to the same effect, in order to make assumption ( i.e., no calling this on idle vcpus) even more clear and as a guard for future mis-use.

xen/common/sched_credit.c +2 -2
index fc3a321..dfe8545 100644
@@ -941,6 +941,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu)
 
     ASSERT( current->processor == cpu );
     ASSERT( svc->sdom != NULL );
+    ASSERT( !is_idle_vcpu(svc->vcpu) );
 
     /*
      * If this VCPU's priority was boosted when it last awoke, reset it.
@@ -957,8 +958,7 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu)
     /*
      * Update credits
      */
-    if ( !is_idle_vcpu(svc->vcpu) )
-        burn_credits(svc, NOW());
+    burn_credits(svc, NOW());
 
     /*
      * Put this VCPU and domain back on the active list if it was

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#1 lore raw

Hello!

Glad to see he patch here. One thing, about the subject line: it should contains "tags", i.e., an indication of the component that the patch affects.

So, for example, in this case, the patch touches Credit1, which means scheduling inside Xen. So, a valid subject line could be:

 [PATCH] xen: sched: removal of redundant check in Credit

or:

 [PATCH] xen: credit: removal of redundant check

Quoted 4 lines · Praveen Kumar

The patch gets rid of a redundant check in csched_vcpu_acct which adds
more code clarity and performance.

I'd remove "which adds more code clarity and performance" and put here something like:

"In fact, the function is only called from csched_tick, which already checks that current is not the idle vcpu."

Quoted 7 lines

This patch also adds an ASSERT to
the same effect, in order to make assumption ( i.e., no calling this on
idle vcpus) even more clear and as a guard for future mis-use.

Apart from what just said above, the patch looks good to me. Can you send version 2 with the changelog updated?

Oh, and I see that you are both inlining in the email and attaching the patch. I personally don't particularly mind, but that may make the life of a committer (the person which, when the patch will have all the Acks, will put it inside the Xen git repository) a bit more difficult.

So, this is mostly George's call, I think, but FWIW, I'd suggest you avoid doing that. :-)

Thanks and Regards,
Dario

Signature · 4 lines
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#2 lore raw
Quoted 10 lines · Dario Faggioli

Oh, and I see that you are both inlining in the email and attaching the patch. I personally don't particularly mind, but that may make the life of a committer (the person which, when the patch will have all the Acks, will put it inside the Xen git repository) a bit more difficult.

So, this is mostly George's call, I think, but FWIW, I'd suggest you avoid doing that. :-)

git send-email is usually easier for everyone (both submitter and committer); but some people’s corporate setup doesn’t allow its use. Jan’s patches are always pasted in-line and attached, for instance.

-George
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel