Fortunately it's no longer a Linux on z only problem anymore. With more systems being run under VMware, KVM, virtualbox etc. the number of people who are being affected is getting larger and, hopefully, that translates into vendors whose applications misbehave being lobbied to get their act together.
On Aug 17, 2010, at 19:41, David Kreuter <dkreu...@vm-resources.com> wrote: > Pat - sure, any intelligent code paths will help. Certainly in a > virtualized environment including but not limited to system z resources > are being shared intensely. The q4 problem (maybe I should trademark > it!) -- errant q3 -- is insidious and damaging. > > These aren't grandpa's CMS machines with small working set sizes. The > machines which are waking up needlessly due to application layer code > typically have very large WSSes. So regardless of path length you have > these virtual beasts competing against each other and legit work > inducing unneeded paging, storage management, etc. > And what is most expensive dollar resource? Unless you are getting the > deal of the millennium it's system Z memory, not the IFLs. > > In general I have found you cannot tune your way out this with SRM > values or other CP settings. Keeping your Linux virtual machine size as > small as you can while providing decent service is advisable, but it > doesn't keep them out of q4. A large DASD paging farm and appropriate > xstore values helps contain this but it not a fix. > > I fail to see why applications are reluctant to determine what > environment they are in and make decisions accordingly. I know and > understand the rationale behind agnostic code but the entire system z > solution for Linux is being hurt by this. > > It just seems unreasonable for any IBM product to be insensitive to > running in a virtual machine. The kernel certainly knows, hey, it even > announces it at boot time! > David Kreuter > > > -------- Original Message -------- > Subject: Re: mono keep guest active > From: Patrick Spinler <spinler.patr...@mayo.edu> > Date: Tue, August 17, 2010 5:51 pm > To: LINUX-390@VM.MARIST.EDU > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David Kreuter wrote: >> The non-hostile list is quite short unfortunately. For the most part >> Oracle is not hostile and queue drops nicely. >> Getting vendors including IBM to: >> 1. acknowledge the problem is hard. >> >> 2. once acknowledged repairing (woops, I mean adding a feature) doesn't >> happen quickly or for that matter often. >> >> In my view it is not criminal or heretic for code to acknowledge its >> virtual surroundings. But lots of apps people think otherwise. >> >> People we just want all our virtual machine children to play and share >> nicely. Give up when you do not have actual work, you will get your turn >> when needed, really you will. Is that too much to ask? >> David Kreuter >> > > It seems to me that this issue has certain parallels to the current and > long running debate about linux kernel power management hacks targeting > embedded devices (e.g. android wake locks) > > Specifically -- applications are very frequently crappy, and fixing them > all, or even a significant fraction of them, is significantly unlikely. > Ergo, what, if anything, could a linux kernel do to reign in > misbehaving apps? > > Android's answer is to sleep regardless of what the apps say, with a > privilege limited mechanism that blocks sleeping. Privs are only > granted to apps the admin (or android packager) deems truely critical > like the radio / phone apps. > > Would some similar sort of mechanism help for virtualization? > (complete, uninformed speculation here) Perhaps a kernel mechanism to > limit wakeups in the case that no cpu is seen to be consumed, or the > like? > > - -- Pat > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxrBHsACgkQNObCqA8uBswOzwCeN8Sdm59uWxiJXRJiYT60FYX7 > 4h8AnixYLgrj2+uGx4O2DgD4yI9ornI+ > =0pfK > -----END PGP SIGNATURE----- > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
