Re: [PATCH] Do not inline virNumaNodeIsAvailable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Apr 25, 2015 at 07:30:21PM +0300, Roman Bogorodskiy wrote:
 Martin Kletzander wrote:

On Tue, Mar 10, 2015 at 02:27:44PM +0100, Ján Tomko wrote:
>On Tue, Mar 10, 2015 at 01:45:38PM +0100, Martin Kletzander wrote:
>> On Tue, Mar 10, 2015 at 12:24:03PM +0000, Daniel P. Berrange wrote:
>> >On Tue, Mar 10, 2015 at 01:05:22PM +0100, Ján Tomko wrote:
>> >> These are the failing qemuxml2argvtest cases:
>> >> 60) QEMU XML-2-ARGV hugepages-pages
>> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
>> >> 63) QEMU XML-2-ARGV hugepages-shared
>> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
>> >> 324) QEMU XML-2-ARGV numatune-memnode
>> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
>> >> 326) QEMU XML-2-ARGV numatune-memnode-no-memory
>> >> ... libvirt:  error : internal error: NUMA node 3 is unavailable
>> >> 329) QEMU XML-2-ARGV numatune-auto-prefer
>> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
>> >>
>> >> So with 4 fake nodes, the tests could still pass even if the function is
>> >> not mocked. Try changing the nodeset in #326 to 4 if it fails.
>> >>
>>
>> I tried changing that, it fails.  I tried adjusting the tests to more
>> nodes, it fails.  After adjusting the mock function again, it works.
>> So it gets mocked all the time, but I know where the difference is,
>> probably.  Try building with -O0, it will probably disable the
>> inlining.  However, if that's the case, I believe it's still clang's
>> fault since they don't document inlining functions without the
>> "inline" keyword just because you optimize.
>>
>
>-O0 does disable the inlining, but introduces the stack size warning.
>
>> >> >
>> >> > >> [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html
>> >> > >> [2] http://clang.llvm.org/compatibility.html
>> >> > >>
>> >> > >> >>---
>> >> > >> >>This only leaves the mysterious check-protocol failure.
>> >> > >>
>> >> > >> That's not that mysterious, it's just that we check the order and
>> >> > >> clang sorts enums before structs, but gcc doesn't.  Also clang adds
>> >> > >> "public:" to structs, so it probably treats it as a C++ or C# structs
>> >> > >> or something?
>> >> > >>
>> >> >
>> >> > By the way if I compile with clang with -std=gnu11 or -std=gnu99, the
>> >> > "public:" stuff is gone :)
>> >> >
>> >>
>> >> It is mysterious, because it doesn't fail consistently.
>>
>> Oh, it does fail all the time for me.
>
>Did I mistakenly build with gcc to fix it?
>
>>
>> >> It was working for me after I tried it again after
>> >> 'git clean -fxd', today it failed again (though I don't remember if I
>> >> ran autogen again).
>> >
>> >How exactly are you running the build with clang ? Are you just doing
>> >this
>> >
>> >  CC=clang ./autogen.sh && make && make check
>> >
>> >Or is there more to it than that ?
>> >
>
>./autogen.sh --system --without-driver-modules CC="clang" && make -j5
>check
>
>Now it failed two times in a row, and once without parallel make. I have
>no idea what I did back then that fixed it.
>

I managed to reproduce your issue!  I used -O2, so that's really it.
I guess that even though clang leaves that code without inlining,
llvm's internal optimizer just screws that up for us.

Anyway, we might fix future problems by disabling inlining for
binaries used for testing, but that would be an overkill when
building.  On the other hand, adding "noinline" to any (possibly)
mocked function seems like the other extreme.

Funny that I didn't notice this thread initially and spotted it while
googling how to debug clang's function inlining while debugging the very
same problem described here.

I have:

$ clang -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation:
$

qemuxml2argvtest fails are 100% reproducible, there are no fails other than
that though.

The patch proposed by Ján fixes the problem for me. Also, it goes away
when I build with CFLAGS=-fno-inline.


Have you (or anyone else in this discussion) found out what else we
might do to fix this?  If not, then we might probably try moving
somewhere with this.  How about using -fno-inline for clang build?

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]