All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Freddie Cash <fjwcash@gmail.com>
Cc: KVM mailing list <kvm@vger.kernel.org>
Subject: Re: Memory leaks in virtio drivers?
Date: Sat, 27 Nov 2010 01:16:23 +0300	[thread overview]
Message-ID: <4CF031B7.4020702@msgid.tls.msk.ru> (raw)
In-Reply-To: <AANLkTikRFqVYjFRoF8Z6OsXa04febk0=e=E8t=bxw2yG@mail.gmail.com>

27.11.2010 00:38, Freddie Cash wrote:
> On Fri, Nov 26, 2010 at 1:00 PM, Michael Tokarev <mjt@tls.msk.ru> wrote:
[]
>> Well, how about reading the changelog first, before asking? They're
>> there for a reason, right?
> 
> I read everything under /usr/share/doc/[qemu|kvm|libvirt], along with
> the release notes on the qemu/kvm websites, and ended up with more
> questions than answers, hence why I posted.  :)  I also read through a
> bunch of old threads on the kvm mailing list, several bug reports for
> qemu, qemu-kvm, libvirt, rhel, and so forth.

No, I mean the changelog for the more recent debian packages.
But it was more of a joke actually, please don't treat it too
seriously.

> The repeating theme through them all was that mem leaks in virtio
> cropped up every other release or so, including some major ones in the
> 0.12.x series (0.12.3 and 0.12.4 especially).  The symptoms we're
> having now are the same ones we originally had with KVM-72 when we
> first switched from SCSI-emulated disks to virtio.

qemu-kvm has a long history of bugs, that's true.
That's why I kept 0.12 in Debian stable, instead
of switching to 0.13.  Lots of code, lots of new
code too, difficult to have it bug-free from the
beginning.

Besides, maybe you hit yet another, still unknown
bug of this theme - which is also a possibility
ofcourse.  No, kvm-0.12.5 (+ a few patches) is
used to run guests in production, with quite
some uptime too, and unlike with <=0.12.4, there
were nothing wrong so far.

>> Speaking of your setup, in addition to what Stephen said already,
>> I'd strongly suggest considering hugepages - for this amount of
>> memory hugepages should help quite alot, and this way you'll eliminate
>> lots of pagetable entries.
> 
> Hrm, I'll have to do some more googling on this.  There's nothing
> about it in the man pages or --help output, but I've seen it
> references on the mailing list.  Same for KSM (as suggested in another
> message), although would that be helpful with such a variety of VM
> guest OSes (Debian Etch, Debian Lenny, Ubuntu Server, Windows XP,
> Windows 2003)?

KSM may help, but it wont work with hugepages (since
the more the page size is, the less chances to find
another page with same contents).

Hugepages - see -mem-path parameter.  It's not widely
known feature.  The idea is that you allocate hugepages
at boot, mount hugetlbfs, and give path to it in -mem-path,
so that instead of malloc() kvm uses mmap() there.  Or
something of that theme.

Hugepages are unswappable and unsharable (KSM), but they're
much lighter in terms of pagetables and tlb misses.

/mjt

  reply	other threads:[~2010-11-26 22:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-26 19:19 Memory leaks in virtio drivers? Freddie Cash
2010-11-26 20:04 ` Stefan Hajnoczi
2010-11-26 20:16   ` Freddie Cash
2010-11-26 20:54     ` Stefan Hajnoczi
2010-11-26 21:14       ` Nikola Ciprich
2010-11-26 21:21       ` Freddie Cash
2010-11-26 21:00 ` Michael Tokarev
2010-11-26 21:38   ` Freddie Cash
2010-11-26 22:16     ` Michael Tokarev [this message]
2010-11-26 23:09       ` Freddie Cash
2010-11-26 23:23         ` Michael Tokarev
2010-12-01 18:16           ` Freddie Cash
2010-12-08 20:21             ` Freddie Cash

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF031B7.4020702@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=fjwcash@gmail.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.