From: nils t. <use...@ni...> - 2004-11-04 15:50:26
|
Moin, in some UMLs i run services which do not like latency, eg. VoIP- and gameserver. I previously observed my UMLs going into meditation for a split second every few seconds, but that bucking almost disappeard by taking the usual tuning steps (SKAS, sysemu, $TMP on tmpfs). Nevertheless, my UMLs are still not as responsive as i would like them to. It's not a matter of CPU or network performance. Host and guest are >=95% idle all the time, bandwidth use is far from my UML-bench- marks. I tried to renice the UML processes, but seems not to help (it's hard to measure, just the "feeling" while listening to audio or onlinegaming). Any suggestions? I enabled "PREEMPT" in host kernel. Maybe that's a bad idea? /nils. -- there is no sig. |
From: Blaisorblade <bla...@ya...> - 2004-11-04 23:46:02
|
On Thursday 04 November 2004 16:50, nils toedtmann wrote: > Moin, > > in some UMLs i run services which do not like latency, eg. VoIP- and > gameserver. I previously observed my UMLs going into meditation for a split > second every few seconds, but that bucking almost disappeard by taking the > usual tuning steps (SKAS, sysemu, $TMP on tmpfs). Nevertheless, my UMLs are > still not as responsive as i would like them to. It's not a matter of CPU > or network performance. Host and guest are >=95% idle all the time, > bandwidth use is far from my UML-bench- marks. > > I tried to renice the UML processes, but seems not to help (it's hard to > measure, just the "feeling" while listening to audio or onlinegaming). > > Any suggestions? > > I enabled "PREEMPT" in host kernel. Maybe that's a bad idea? This problem is an old one. Search the archives for "odd ping problems", which is about long ping delay. A fix was proposed a while ago, which consisted in mlock()ing the memory. But Jeff Dike refused it because he said "I want to write a much more complex and more optimal solution. Mlock() is an hack". Even so, I'll try to update the patch, fix it on the security side (that one required setuid()'ing UML, which is purposeless) and push it for inclusion, if possible. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nuno S. <nun...@vg...> - 2004-11-05 02:54:38
|
Blaisorblade wrote: ... > A fix was proposed a while ago, which consisted in mlock()ing the memory. But > Jeff Dike refused it because he said "I want to write a much more complex and > more optimal solution. Mlock() is an hack". Maybe having the linux binary in a ramfs will work better? You can also do some creative mount --bind, to mount only one ramfs instance, if you have many UMLs running. Regards, Nuno Silva |
From: Blaisorblade <bla...@ya...> - 2004-11-05 19:37:43
|
On Friday 05 November 2004 03:54, Nuno Silva wrote: > Blaisorblade wrote: > > ... > > > A fix was proposed a while ago, which consisted in mlock()ing the memory. > > But Jeff Dike refused it because he said "I want to write a much more > > complex and more optimal solution. Mlock() is an hack". Actually he said something much more complex than that. You can find his worries in this email. > Maybe having the linux binary in a ramfs will work better? Wise idea! But you forgot the UML "RAM" from $TMPDIR. Ramfs data are not swappable, so using that both for the UML binary and for * $TMPDIR * should work. However, Jeff wouldn't have a different opinion on this, but it can be done without patching UML. In fact, he worries about the host going OutOfMemory or anyway actually needing hard to swap out memory; this could even happen when, for instance, UML is using all memory just for caching (and maybe caching unused data). In the meanwhile, while one UML caches an use-only-once file, the host goes OutOfMemory and kills one UML instance. He wanted the UMLs to release memory to the host when needed. This, however, is not a problem for dedicated UML hosting if you don't oversell UML ram. > You can also do some creative mount --bind, to mount only one ramfs > instance, if you have many UMLs running. Not needed I think - use different names for UML binaries as needed. It will pickup a good name for the RAM file. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nuno S. <nun...@vg...> - 2004-11-06 06:08:57
|
Blaisorblade wrote: >>Maybe having the linux binary in a ramfs will work better? > > Wise idea! But you forgot the UML "RAM" from $TMPDIR. No i didn't :-) And i advise against it because of the problems that you point out below (OOM). Anyway, if the data is frequently used it won't be sent to swap... If you only touch that data once every 5 minutes and you have some memory pressure you may get a bigger latency. If you must have fast-as-it-gets memory access making several UBDs, one of them very small in ramfs, may be better, YMMV. ... >>You can also do some creative mount --bind, to mount only one ramfs >>instance, if you have many UMLs running. > > Not needed I think - use different names for UML binaries as needed. It will > pickup a good name for the RAM file. I was thinking about chroot environments. And saving some MB by using the same binary - living in ramfs - to run many UMLs. Regarding double-cacheing you may try NFS or directIO (with directIO the guest can create disk I/O even if it's not needed and ruin the host's I/O performance). Again, YMMV. Thanks, Nuno Silva |