[vfio-users] Calling ALL VM experts - Seeking assistance with AMD FX CPUs

[Alyx]

I've tried hugepages (guess I forgot to list it). Added it to the XML and
appended it to the kernel parameters, as described in the wiki, still no
difference.
It's just pretty strange that this issue only exists in a VM environment,
and any optimisations made make minimal to no difference.

If I was to boot up the VM into Linux are there any tests I can do in a
Linux VM environment to help figure out what the issue is? Since no options
seem to reveal the problem and I presume Linux has more tools to deduce the
specifics of this issue.

On Tue, Jan 31, 2017 at 9:30 PM, Zachary Boley <zboley00 at gmail.com> wrote:

> It seems everything is alright, I would try hugepages and see if that
> helps it describes how to do it in the arch wikis guide on pci passthrough
>
> On Jan 30, 2017 10:48 PM, "Alyx" <overlordalyx at gmail.com> wrote:
>
>> Hopefully this reply works.
>> So. I have an FX-8350. I have the exact issue as described, and believe
>> the person he was talking about.
>>
>> Here's my config - http://pastebin.com/McuiqyDt
>> Note that the above config is just the one I am running just now and has
>> some options that have no effect, such as "vmport=off", in a desperation
>> attempt to see if any option makes a difference.
>>
>> So I've tried many things to get the stuttering to subside. I've tried,
>> changing the kernel tick-rate, changing to a realtime kernel, changing to
>> the CK kernel (with the belief that a different I/O scheduler might solve
>> it), making the VM BIOS, changing the pre-emptive state of the kernel,
>> changing the PCIE slot of the GPU (so that it is now in slot 1, and the
>> "main" GPU in slot 2), isolating cores, hugepages, moving threads via cset.
>> And of course a combination of all of the above. The only thing that sort
>> of solves it if I reduce the number of cores I pass to the VM, more than 4
>> and it increases the stuttering, and less than 4 makes it not really
>> powerful enough for higher-end gaming.
>>
>> There was a random thought that it could've been something to do with the
>> shared FPU, however after isolating the last 6 cores and only passing every
>> second core (3, 5, 7) so that they are on separate FPU modules (meaning
>> that it's "pair" is not doing any work at all), yields the same results as
>> passing 3 cores normally.
>>
>> I would describe the issue as a stuttering of sorts, where the game
>> freezes and then suddenly speeds up to catch back up to realtime (sound
>> usually works as normal during the stutter as if nothing happened). It's
>> fine within a desktop environment and when doing benchmarks such as
>> Cinebench and Unigine-Heaven (Heaven being exactly the same as bare metal).
>> However it's when I move into a more game-like situation such as 3D Mark's
>> benchmarks where the stuttering appears. Some 3D Mark benchmarks can even
>> cause the VM/Program to freeze such as the API overhead test which also
>> displays a large amount of stuttering during the test (assuming it doesn't
>> crash half way though of course). Another program-specific issue is that
>> the program HWINFO also locks up the entire VM when it tries to detect the
>> CPU (works on Intel hardware) causing Windows to shut down after a ~10
>> seconds. Sure the HWINFO isn't too much of an issue, but it could be
>> related.
>> The stuttering becomes more apparent as the game tries to load in
>> textures, for example exiting out of a safe area into a large open world
>> (Game: The Division) causes huge amounts of stuttering until everything has
>> finished "popping-in". However, once everything has loaded in, if I look at
>> the frametimes in MSI Afterburner I can see that it varies dramatically, so
>> I'll be at 60 FPS and see the frametimes jump from low ~20ms to 100ms+ with
>> no "big" stuttering like when the textures are loading.
>>
>> Any help is appreciated and I'll try any suggestions at this point
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20170201/53c0f1ac/attachment.htm>