id,summary,reporter,owner,description,type,status,component,version,resolution,keywords,cc,guest,host 15416,Operation of swap partition in Linux Gentoo guest OS slows VM to a crawl,dogbone,,"Gentoo Linux hardware OS, Virtualbox 4.3.32/5.0.20 and Gentoo guest OS Compiling Firefox (and other large compiles like the kernel, webkit, llvm) in the guest OS is a problem. Compiling Firefox et al on the hardware OS is fine. Hardware has 4 CPUs(and 8 threads), 6GB of RAM Guest OS started off with 2GB of RAM and 8CPUs, MAKE_OPTS=""-j9"" for compiler. Compiling of Firefox gradually ground almost to a halt, although it was able to recover a bit from time to time. I found a bug report that suggested it was OK if only 1CPU was supplied to the guest OS. Increased guest OS RAM to maximum (3.5GB) before VB gave a warning and reduced CPUs to one. Ran compile until a bit of action started in 'top' on both hardware and guest OSs. Wait states in the guest OS would rise sharply when swap space use was increasing and the VB process in the hardware OS would start to drop %CPU from 100%. Stopped compile and set guest OS CPUs to 2 (all with -j9 makeopt parameter to keep memory use up). Fault appeared earlier and more strongly. Wait states on both guest OS CPUs were hitting more than 90% at the same time. Hardware CPU cycles fell to lows of about 20% from 200%. Once this rise in wait states starts, it seems to stay and get worse, reaching the high 90%s on all guest CPUs. The wait states seem to directly correlate to swap space activity. Currently, as firefox compile continues, free memory = 1.5GB used memory = 2.0GB buffer/cache =67k # Seems the buffer/cache has migrated to the swap space swap =1.3GB # Ditto free swap =3.5GB wait states stable(ish) at 93% on both guest OS CPUs Hardware OS at 16%CPU instead of 200% but it can recover a bit from time to time Shutdown and increased guest CPUs to 4, switched off (>swapoff -a) guest OS swap and reduced guest makeopts to -j4. Hardware OS Virtualbox process staying steady at 400%. Guest OS at about 750k free memory, 1GB used and 1.8GB buffer/cache and no wait states. 4 CPUs seem to compile OK with makeopts=-j4 and 3.5GB of RAM in the guest OS with no swap and the hardware OS just sits at 400%. Trying for 800% brought kswapd0 to the top of the process list: failure without more RAM. Upgraded to VB5.0.20 from VB4.3.32 through portage and repeated tests. Seems to me that Virtualbox has a problem reducing its swap space usage and returning to using the buffer/cache. The resulting wait states kill the performance. Temporary fix is to supply maximum RAM to guest OS and switch off swap. The problem is present in both VB4.3.32 and VB5.0.20.",defect,closed,other,VirtualBox 5.0.20,obsolete,linux guest swap wait states,,Linux,Linux