From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, wei.liu2@citrix.com, Ian.Campbell@citrix.com,
stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
david.vrabel@citrix.com, keir@xen.org
Subject: Re: [PATCH 5/5] xen: clean up VPF flags macros
Date: Mon, 28 Sep 2015 09:29:31 +0200 [thread overview]
Message-ID: <5608EC5B.3060106@suse.com> (raw)
In-Reply-To: <5608F8AE02000078000A5F6E@suse.com>
On 09/28/2015 08:22 AM, Jan Beulich wrote:
>>>> On 28.09.15 at 07:23, <JGross@suse.com> wrote:
>> On 09/25/2015 05:42 PM, Jan Beulich wrote:
>>>>>> On 25.09.15 at 13:54, <JGross@suse.com> wrote:
>>>> Per-VCPU pause flags in sched.h are defined as bit positions and as
>>>> values derived from the bit defines. There is only one user of a value
>>>> which can be easily converted to use a bit number as well.
>>>
>>> I'm not convinced:
>>>
>>>> --- a/xen/common/domctl.c
>>>> +++ b/xen/common/domctl.c
>>>> @@ -172,7 +172,7 @@ void getdomaininfo(struct domain *d, struct
>> xen_domctl_getdomaininfo *info)
>>>> info->max_vcpu_id = v->vcpu_id;
>>>> if ( !test_bit(_VPF_down, &v->pause_flags) )
>>>> {
>>>> - if ( !(v->pause_flags & VPF_blocked) )
>>>> + if ( !test_bit(_VPF_blocked, &v->pause_flags) )
>>>
>>> test_bit() is quite a bit more complex an operation than a simple &,
>>> and with (on x86) even constant_test_bit() involving a cast to
>>> a pointer to volatile I'm afraid we can't even hope that compilers
>>> would produce identical code for both in cases like this one (as that
>>> casts limits freedom of the compiler). IOW I'd rather see other
>>> test_bit(_VPF_...) uses converted the inverse way (which as a nice
>>> but minor side effect would yield slightly smaller source code).
>>
>> What about introducing __test_bit() being a variant which can be
>> reordered by omitting the volatile modifier? I think this would have
>> the same effect.
>
> I'm not convinced it always would - the inline function is still more
> complex than the plain operation.
Depends on the way it is done. What about:
#define __test_bit(nr, addr) ({ \
if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
(__builtin_constant_p(nr) ? \
!!(*(addr) & ((typeof)(*(addr))1 << (nr))) : \
__variable_test_bit((nr),(addr))); \
})
It would even be possible to drop the test for bitop_bad_size(addr) in
the constant case.
>> And we could still get rid of many double definitions
>> of the same bit. Even if the mask definition of a bit is not error prone
>> by relying on the definition of the bit position, it makes it harder to
>> find all users of this bit.
>
> Why so? Just omit the leading underscore when grep-ing, and you'll
> find all instances (less preprocessor token concatenation, but that's
> orthogonal).
I do use grep for this purpose occasionally, but I prefer tools like
cscope. BTW: IMO using grep the way you are suggesting here is annoying
for cases where the search string is contained in other items.
Juergen
next prev parent reply other threads:[~2015-09-28 7:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 11:54 [PATCH 0/5] various clean-ups Juergen Gross
2015-09-25 11:54 ` [PATCH 1/5] libelf: use enum instead of hard coded values in elf_dom_parms.pae Juergen Gross
2015-09-25 11:54 ` [PATCH 2/5] xen: make use of new pae enum in hypervisor Juergen Gross
2015-09-25 15:29 ` Jan Beulich
2015-09-25 11:54 ` [PATCH 3/5] libxc: make use of new pae enum in libxc Juergen Gross
2015-09-25 12:00 ` Ian Campbell
2015-09-25 15:30 ` Jan Beulich
2015-09-25 11:54 ` [PATCH 4/5] xen: remove unused macros from sched.h Juergen Gross
2015-09-28 10:27 ` George Dunlap
2015-09-25 11:54 ` [PATCH 5/5] xen: clean up VPF flags macros Juergen Gross
2015-09-25 15:42 ` Jan Beulich
[not found] ` <5605878D02000078000A5BA1@suse.com>
2015-09-28 5:23 ` Juergen Gross
2015-09-28 6:22 ` Jan Beulich
[not found] ` <5608F8AE02000078000A5F6E@suse.com>
2015-09-28 7:29 ` Juergen Gross [this message]
2015-09-28 7:52 ` Jan Beulich
[not found] ` <56090DDF02000078000A6042@suse.com>
2015-09-28 8:15 ` Juergen Gross
2015-09-28 8:34 ` Jan Beulich
[not found] ` <560917CE02000078000A6085@suse.com>
2015-09-28 8:44 ` Juergen Gross
2015-09-25 12:02 ` [PATCH 0/5] various clean-ups Andrew Cooper
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=5608EC5B.3060106@suse.com \
--to=jgross@suse.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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.