On Friday 03 April 2009 02:52:49 Martin Schwidefsky wrote: > On Thu, 2 Apr 2009 22:32:00 +1100 > Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote: > > > On Monday 30 March 2009 01:23:36 Martin Schwidefsky wrote: > > > On Sat, 28 Mar 2009 17:05:28 +1030 > > > > > > Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: > > > > On Saturday 28 March 2009 01:39:05 Martin Schwidefsky wrote: > > > > > Greetings, > > > > > the circus is back in town -- another version of the guest page hinting > > > > > patches. The patches differ from version 6 only in the kernel version, > > > > > they apply against 2.6.29. My short sniff test showed that the code > > > > > is still working as expected. > > > > > > > > > > To recap (you can skip this if you read the boiler plate of the last > > > > > version of the patches): > > > > > The main benefit for guest page hinting vs. the ballooner is that there > > > > > is no need for a monitor that keeps track of the memory usage of all > > > > > the guests, a complex algorithm that calculates the working set sizes > > > > > and for the calls into the guest kernel to control the size of the > > > > > balloons. > > > > > > > > I thought you weren't convinced of the concrete benefits over ballooning, > > > > or am I misremembering? > > > > > > The performance test I have seen so far show that the benefits of > > > ballooning vs. guest page hinting are about the same. I am still > > > convinced that the guest page hinting is the way to go because you do > > > not need an external monitor. Calculating the working set size for a > > > guest is a challenge. With guest page hinting there is no need for a > > > working set size calculation. > > > > Sounds backwards to me. If the benefits are the same, then having > > complexity in an external monitor (which, by the way, shares many > > problems and goals of single-kernel resource/workload management), > > rather than putting a huge chunk of crap in the guest kernel's core > > mm code. > > The benefits are the same but the algorithmic complexity is reduced. > The patch to the memory management has complexity in itself but from a > 1000 feet standpoint guest page hinting is simpler, no? Yeah but that's a tradeoff I'll begrudgingly make, considering a) lots of people doing workload management inside cgroups/containers need similar algorithmic complexity so improvements to those algorithms will help one another b) it may be adding complexity, but it isn't adding complexity to a subsystem that is already among the most complex in the kernel c) i don't have to help maintain it > The question > how much memory each guest has to release does not exist. With the > balloner I have seen a few problematic cases where the size of > the balloon in principle killed the guest. My favorite is the "clever" > monitor script that queried the guests free memory and put all free > memory into the balloon. Now gues what happened with a guest that just > booted.. > > And could you please explain with a few more words >what< you consider > to be "crap"? I can't do anything with a general statement "this is > crap". Which translates to me: leave me alone.. :) No it's cool code, interesting idea etc, and last time I looked I don't think I saw any fundamental (or even any significant incidental) bugs. So I guess my problem with it is that it adds complexity to benefit a small portion of users where there is already another solution that another set of users already require. > > I still think this needs much more justification. > > Ok, I can understand that. We probably need a KVM based version to show > that benefits exist on non-s390 hardware as well. Should be significantly better than ballooning too. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
