From: Joerg Roedel <joro@8bytes.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>, Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH] kvm/qemu: use statfs to determine size of huge pages
Date: Sun, 22 Feb 2009 19:29:57 +0100 [thread overview]
Message-ID: <20090222182957.GL2125@8bytes.org> (raw)
In-Reply-To: <20090221001842.GA8300@amt.cnet>
On Fri, Feb 20, 2009 at 09:18:42PM -0300, Marcelo Tosatti wrote:
> Hi Joerg,
>
> On Thu, Feb 19, 2009 at 04:29:36PM +0100, Joerg Roedel wrote:
> > The current method of finding out the size of huge pages does not work
> > reliable anymore. Current Linux supports more than one huge page size
> > but /proc/meminfo only show one of the supported sizes.
> > To find out the real page size used can be found by calling statfs. This
> > patch changes kvm/qemu to use statfs instead of parsing /proc/meminfo.
> >
> > Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
>
> > + if (fs.f_type != HUGETLBFS_MAGIC) {
> > + fprintf(stderr, "Path not on HugeTLBFS: %s\n", path);
> > + return 0;
> > }
>
> Would be nicer to use standard page size (sysconf) in case its not a
> hugetlbfs mount, instead of failing. Useful for testing with shmem.
>
> > - size = strstr(buf, needle);
> > - if (!size)
> > - return 0;
> > - size += strlen(needle);
> > - hugepagesize = strtol(size, NULL, 0);
> > - return hugepagesize;
> > + return fs.f_bsize;
> > }
> >
> > static void *alloc_mem_area(size_t memory, unsigned long *len, const char *path)
> > @@ -4762,7 +4760,7 @@ static void *alloc_mem_area(size_t memory, unsigned long *len, const char *path)
> > if (asprintf(&filename, "%s/kvm.XXXXXX", path) == -1)
> > return NULL;
> >
> > - hpagesize = gethugepagesize() * 1024;
> > + hpagesize = gethugepagesize(path);
> > if (!hpagesize)
> > return NULL;
>
> Out of curiosity, your immediate reason for this patch is use of
> gbpages?
Yes. I am currently preparing patches to support gbpages in KVM. I think
they will be ready for submission next week.
The leak bugs were also found when I was debugging the code this week.
My test system has 5 gbpages an leaking one or two of them is _really_
bad ;)
Joerg
prev parent reply other threads:[~2009-02-22 18:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 15:29 [PATCH] kvm/qemu: use statfs to determine size of huge pages Joerg Roedel
2009-02-21 0:18 ` Marcelo Tosatti
2009-02-22 18:29 ` Joerg Roedel [this message]
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=20090222182957.GL2125@8bytes.org \
--to=joro@8bytes.org \
--cc=avi@redhat.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/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.