Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field â<anonymous>â

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.08.15 at 19:41, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
>> On Tue, Aug 25, 2015 at 05:48:58PM +0100, Andrew Cooper wrote:
>>> On 25/08/15 17:43, Konrad Rzeszutek Wilk wrote:
>>>> I am troubleshooting an locking issue and figured I would enable extra 
> options.
>>>>
>>>> But now I am hitting this build issue:
>>>>
>>>> domain.c:241: error: negative width in bit-field â<anonymous>â
>>>>
>>>> Which is:
>>>>
>>>>  229 struct domain *alloc_domain_struct(void)
>>>>  230 {
>>>>  231     struct domain *d;
>>>> ...
>>>>  241     BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>>>
>>>> Thoughts?
>>> That is to catch the case where sizeof struct domain exceeds PAGE_SIZE.
>>>
>>> The logic behind this was to prevent needing order 1 allocations for
>>> domains or vcpus, and therefore allocation failures in heavily memory
>>> fragmented situations.
>>>
>>> It means we will probably need to find some other areas of struct domain
>>> to shrink, or move out into a separate xmalloc().
>>>
>>> For straight debugging, it is acceptable to drop the BUILD_BUG_ON().  If
>>> we can't drop the size of struct domain, we might want to move to using
>>> vmalloc() instead.
>> It is big. pahole says:
>>
>>    /* size: 4352, cachelines: 68, members: 74 */ 
>>     /* sum members: 4238, holes: 9, sum holes: 34 */ 
>>     /* padding: 80 */ 
>>     /* paddings: 1, sum paddings: 4 */
> 
> So by rearranging to reduce padding, it would easily fit ;p

How that? 4238 > 4096.

Jan

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