On Fri, Sep 04, 2009 at 06:19:29PM +0300, Dan Kenigsberg wrote:
On Thu, Sep 03, 2009 at 01:05:47PM +0100, Daniel P. Berrange wrote:
> On Thu, Sep 03, 2009 at 02:49:23PM +0300, Dan Kenigsberg wrote:
> > If you are running a number of qemu-kvm's with similar guests, you can
> > gain a lot of memory by using ksm properly.
> >
> > An unattended host running a variable number of qemu-kvm's needs to tune
> > ksm automatically, since when memory is tight, it's better to spend more
> > cpu on merging pages. In more relaxed cases, it's just a waste of time.
> >
> > The attached service tries to do just that.
> >
> > It monitors how much memory is used by qemu-kvm processes, and starts
> > ksm when a threshold is passed. Ksm usually manages to free up some
> > memory.
> >
> > As long as memory used by qemu is above the defined threshold, ksm tries
> > harder and harder to share memory pages (up to a limit). This may happen
> > if a guest starts working and consumes new memory. If there's enough
> > free memory, ksm cools down.
> >
> > Ksmd service has the usual start/status/stop verbs, and an additional
> > one: signal. One should use that verb just after one starts a new
> > qemu-kvm process or just after such process dies, to let ksm adjust
> > immediately.
> >
> > Comments and suggestion are welcome.
>
> Looks like a nice idea.
>
> I'd be inclined to split this file up a little to get separation of
> the init script bits, from the tuning logic, and to allow ksm / tuning
> to be managed more independantly, eg
>
> - /etc/init.d/ksmd - to start/stop ksmd
> - /etc/init.d/ksmtuned - to start/stop the automatic tuning process
> - /usr/sbin/ksmtuned - the logic from the loop() function & things it calls
>
>
> That makes it easier for other distros to share the important bits - eg
> the actual tuning logic, even if they use different initscript system
I can see the merit in splitting to /usr/sbin/ksmtuned (though who cares
about other distros !?).
But why should we want two services? I would like ksmtuned to stop ksm
completely when it is not needed (and start it up if needed), so what
ksmd would be good for?
Management applications / developers might like to implement/use a
different way of tuning KSM. Thus we should be able to start the
core KSM service, without also starting the KSM tuning service.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|