Re: [PATCH] sched_credit: Remove cpu argument to __runq_insert()

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1953 bytes --]

On Tue, 2015-11-03 at 05:38 -0700, Jan Beulich wrote:
> > > > On 03.11.15 at 11:16, <George.Dunlap@eu.citrix.com> wrote:

> > So you agree that this change makes the source code make more sense
> > ("looks like an improvement at the source level"), but you think
> > that
> > this will make the compiled code less efficient; and you recommend
> > instead of making the source code clearer, to make things even
> > *better* by changing the BUG_ON() to an ASSERT?
> > 
> > Why do you think the compiler output will be less efficient?
> 
> Due to the two extra memory references, which the compiler is
> unlikely to be able to eliminate in all cases?.
> 
Right. I had a quick look at the assembly code, and I think I saw
something like that. As far as I've seen, though, the text sections of
the generated binaries --with and without this patch-- were equally big
(due to alignment, I think).

Also, for the reasons explained here:
 http://lists.xen.org/archives/html/xen-devel/2015-11/msg00051.html

As far as I'm concerned, this patch is:

Acked-by: Dario Faggioli <dario.faggioli@citrix.com>

That being said...

> > Overall I think the burden of proof is on you to show that the code
> > as
> > it is introduces a sufficient performance improvement over the more
> > readable code, rather than on Harmandeep (or Dario or I) to show
> > that
> > it doesn't.
> 
> Okay, so far I thought people suggesting a change are the ones
> to prove that the change doesn't have undesirable effects. 
>
...just FTY, I probably will try having a look at what it means to make
__runq_insert() non-inline. But that's another patch. :-)

Thanks and Regards,
Dario
-- 
<<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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel