From: "Daniel P. Berrange" <berrange@redhat.com>
To: Linhaifeng <haifeng.lin@huawei.com>
Cc: mst@redhat.com, qemu-devel@nongnu.org, jerry.lilijun@huawei.com
Subject: Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage
Date: Mon, 20 Oct 2014 08:54:57 +0100 [thread overview]
Message-ID: <20141020075457.GA19687@redhat.com> (raw)
In-Reply-To: <5441DC6D.2060602@huawei.com>
On Sat, Oct 18, 2014 at 11:20:13AM +0800, Linhaifeng wrote:
>
>
> On 2014/10/17 21:26, Daniel P. Berrange wrote:
> > On Fri, Oct 17, 2014 at 04:57:27PM +0800, Linhaifeng wrote:
> >>
> >>
> >> On 2014/10/17 16:33, Daniel P. Berrange wrote:
> >>> On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng.lin@huawei.com wrote:
> >>>> From: linhaifeng <haifeng.lin@huawei.com>
> >>>>
> >>>> The VM start with share hugepage should close the hugefile fd
> >>>> when exit.Because the hugepage fd may be send to other process
> >>>> e.g vhost-user If qemu not close the fd the other process can
> >>>> not free the hugepage otherwise exit process,this is ugly,so
> >>>> qemu should close all shared fd when exit.
> >>>>
> >>>> Signed-off-by: linhaifeng <haifeng.lin@huawei.com>
> >>>
> >>> Err, all file descriptors are closed automatically when a process
> >>> exits. So manually calling close(fd) before exit can't have any
> >>> functional effect on a resource leak.
> >>>
> >>> If QEMU has sent the FD to another process, that process has a
> >>> completely separate copy of the FD. Closing the FD in QEMU will
> >>> not close the FD in the other process. You need the other process
> >>> to exit for the copy to be closed.
> >>>
> >>> Regards,
> >>> Daniel
> >>>
> >> Hi,daniel
> >>
> >> QEMU send the fd by unix domain socket.unix domain socket just install the fd to
> >> other process and inc the f_count,if qemu not close the fd the f_count is not dec.
> >> Then the other process even close the fd the hugepage would not freed whise the other process exit.
> >
> > The kernel always closes all FDs when a process exits. So if this FD is
> > not being correctly closed then it is a kernel bug. There should never
> > be any reason for an application to do close(fd) before exiting.
> >
> > Regards,
> > Daniel
> >
> Hi,daniel
>
> I don't think this is kernel's bug.May be this a problem about usage.
> If you open a file you should close it too.
No, the standard UNIX semantics are that the kernel will close all
file descriptors when a process exits. There is *no* requirement to
manually close any file descriptors before exiting.
The only time you need to close files is if you are using a higher
level API (eg C library "FILE *" ) and you need to explicitly flush
any buffered I/O operations before exiting. This doesn't apply in the
case of huge pages.
> Run the first VM.QEMU deal with hugepage as follow steps:
> 1.open
> 2.unlink
> 3.mmap
> 4.use memory of hugepage and send the fd to vapp with unix domain socket.After this step the meminfo is:
If the QEMU process has exited then the kernel has closed the FD that
QEMU had open. The logical implication is that the 'vapp' process still
has its copy of the file descriptor open even after QEMU has exited.
Another possibility is that whatever launched QEMU has not done a waitpid
and thus leaving QEMU in a zombie state where file descriptors are not
yet cleaned up.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2014-10-20 7:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-17 8:27 [Qemu-devel] [PATCH] fix the memory leak for share hugepage haifeng.lin
2014-10-17 8:33 ` Daniel P. Berrange
2014-10-17 8:56 ` Gonglei
2014-10-17 9:13 ` Linhaifeng
2014-10-17 8:57 ` Linhaifeng
2014-10-17 9:21 ` Linhaifeng
2014-10-17 13:26 ` Daniel P. Berrange
2014-10-18 3:20 ` Linhaifeng
2014-10-20 2:12 ` Wen Congyang
2014-10-20 4:48 ` Linhaifeng
2014-10-20 5:32 ` Wen Congyang
2014-10-20 6:17 ` Linhaifeng
2014-10-20 6:26 ` Wen Congyang
2014-10-20 7:50 ` Linhaifeng
2014-10-20 7:54 ` Daniel P. Berrange [this message]
2014-10-17 8:43 ` zhanghailiang
2014-10-18 3:22 ` Linhaifeng
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=20141020075457.GA19687@redhat.com \
--to=berrange@redhat.com \
--cc=haifeng.lin@huawei.com \
--cc=jerry.lilijun@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).