From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuUAb-0002yp-SU for qemu-devel@nongnu.org; Wed, 13 Dec 2006 08:29:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuUAa-0002xR-Pw for qemu-devel@nongnu.org; Wed, 13 Dec 2006 08:29:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuUAa-0002x4-JD for qemu-devel@nongnu.org; Wed, 13 Dec 2006 08:29:12 -0500 Received: from [62.219.232.206] (helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GuUAa-0000Jg-CT for qemu-devel@nongnu.org; Wed, 13 Dec 2006 08:29:12 -0500 Message-ID: <45800026.2010809@qumranet.com> Date: Wed, 13 Dec 2006 15:29:10 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: NBD server for QEMU images References: <20061212124803.47702.qmail@web52708.mail.yahoo.com> <457EC621.6000701@codemonkey.ws> <457F0D61.90008@codemonkey.ws> <457FE5EE.4000704@qumranet.com> <56d259a00612130519l2b324966o2f2cd6e5c69beb10@mail.gmail.com> In-Reply-To: <56d259a00612130519l2b324966o2f2cd6e5c69beb10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Martin Guy wrote: >> - write tons of data to nbd device, data ends up in pagecache >> - memory gets low, kswapd wakes up, calls nbd device to actually write >> the data >> - nbd issues a request, which ends up on the nbd server on the same >> machine >> - the nbd server allocates memory >> - memory allocation hangs waiting for kswapd > > In other words, it can deadlock only if you are swapping to an nbd > device that is served by nbd-server running on the same machine and > kernel. No. It is possible if you issue non-O_SYNC writes. > In the case of a qemu system swapping over nbd to a server on > the host machine, it is the guest kernel that waits on the host kernel > paging the nbd server in from the host's separate swap space, so no > deadlock is possible. > > Practice bears this out; if you wanna stress-test it, here's a program > that creates a low memory condition by saturating the VM. It isn't enough to thrash the guest, you need to exhaust host memory as well. You also need to do it faster than kswapd can write it out. > > Of course, this has nothing to do with the original patch, which just > lets nbd-server interpret qemu image files ;) > Agreed. But mounting nbd from localhost is dangerous. -- error compiling committee.c: too many arguments to function