Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1228773imj; Sun, 17 Feb 2019 00:46:14 -0800 (PST) X-Google-Smtp-Source: AHgI3IaKupmrzypUw4r4HJgNO9UyTfBjZ33cvM4zvGFbkM0HIWN6p+2LKzb+25+81qFV16VfxWss X-Received: by 2002:a63:1c42:: with SMTP id c2mr13235939pgm.265.1550393174161; Sun, 17 Feb 2019 00:46:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550393174; cv=none; d=google.com; s=arc-20160816; b=0cLF6Tbb4CT3FbqfZ0y08ZTB2bL0AFEPt9fWzqefSYSTqrsp3hHaIUxtls1J9eRx70 C10Y+mXobB9volJ+olukfkrPswX8zhkSzUkAxHmSgpa8onBJh1vr/15vjmysWtnd0rIW CfXEHN4oOz9af2HZ8ksM4YwX/16TDTYq6ft4SFej0fWfBE5rrekkTDmCkAz5VJzWjmIl BIgSm356Nq5ucfQvkCWgC9S/LLXURRoKfSORsIPp+t+DmmxZj7IxAZ02/CRVQrz/7PHx 6JI3weZm+HtAaXqZsScHiKxpN57yMcef6ln9KN4GDh7unm5s8mMKJgWkyhEv01QAKlEh WgcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dgU8YNmf3tkH+oeJ2gArygLgRhFyPGnZqmFtLfcD8as=; b=QbrMGNGEOrmzKg8m/EeNrjcoZuXQ4H+F1tQRKU46CWBBD9zIFUf7M3GBshiRY9NrdB qaNCcFl2ADC9duKomh0nFmQnmiGpUYhfBL40SksEscfzDNGZJ8Q/2vebuQFOOTjvGEW9 8lkXZN14gMHpwXpDDiaV9FWpBeeRxX0Dz1G2/hj+TG8SNoD66EGSGGxcZFlns//FR8Uj qsALszipVGwH5a5ZVVFjRQqJAdkEQSXkfrRkI5zUbvGoZ616q85j4e54nU80kVqCKn0y mgxuDSlp9gqYTg9Cv0o5kiLFIIbbrTcH5qpvxBdXdvEdelvJuz8jwlffamPf90VAjMse 7PxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c3si7041958plr.178.2019.02.17.00.45.58; Sun, 17 Feb 2019 00:46:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbfBQIpC (ORCPT + 99 others); Sun, 17 Feb 2019 03:45:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60102 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbfBQIpA (ORCPT ); Sun, 17 Feb 2019 03:45:00 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ECDBA5A7A; Sun, 17 Feb 2019 08:44:59 +0000 (UTC) Received: from localhost (ovpn-117-203.ams2.redhat.com [10.36.117.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81B94101E846; Sun, 17 Feb 2019 08:44:59 +0000 (UTC) Date: Sun, 17 Feb 2019 08:44:58 +0000 From: "Richard W.M. Jones" To: Pavel Machek Cc: kernel list , Andrew Morton Subject: Re: nbd, nbdkit, loopback mounts and memory management Message-ID: <20190217084458.GY12500@redhat.com> References: <20190215191953.GB17897@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190215191953.GB17897@amd> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Sun, 17 Feb 2019 08:45:00 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org So not to dispute that this could be a bug, but I couldn't cause a deadlock. I wonder if you can see something wrong with my method? *** Set up *** - kernel 5.0.0-0.rc3.git0.1.fc30.x86_64 - nbd-client 3.19-1.fc30 - nbdkit 1.11.5 (git commit ef9d1978ce28) Baremetal machine was booted with mem=2G to artificially limit the RAM. The machine has 64G of swap. # free -m total used free shared buff/cache available Mem: 1806 329 1383 0 93 1357 Swap: 65535 179 65356 *** Method *** I started nbdkit as a 4G RAM disk: ./nbdkit memory size=4G This is implemented as a sparse array with a 2 level page table, and should allocate (using malloc) every time a new area of the disk is written to. Exact implementation is here: https://github.com/libguestfs/nbdkit/tree/master/common/sparse I started nbd-client using the -swap option which uses mlockall(MCL_FUTURE) to lock the client into RAM. nbd-client -b 512 -swap localhost /dev/nbd0 I then created a filesystem on the RAM disk, mounted it, and copied a 3G file into it. I tried this various ways, but the variation I was eventually happy with was: mke2fs /dev/nbd0 mount /dev/nbd0 /tmp/mnt dd if=/dev/zero of=/tmp/big bs=1M count=3000 cp /tmp/big /tmp/mnt/big I couldn't get any kind of deadlock or failure in this test. (Note that if you repeat the test several times, in theory you could delete the file and fstrim the filesystem, but when I was testing it to be sure I unmounted everything and killed and restarted nbdkit between each test.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v