All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Richard W.M. Jones" <rjones@redhat.com>, smcdowell@cloudbd.io
Cc: kernel list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: nbd, nbdkit, loopback mounts and memory management
Date: Mon, 18 Feb 2019 00:15:14 +0100	[thread overview]
Message-ID: <20190217231514.GA10675@amd> (raw)
In-Reply-To: <20190217084458.GY12500@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

Hi!

> 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.)

This looks like quite a good try. I'd try to use mmap() to dirty
memory very quickly.

But Shaun reported it happened somehow often for them, so he might
have a practical test case... better than my theories :-).

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2019-02-17 23:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 19:19 nbd, nbdkit, loopback mounts and memory management Pavel Machek
2019-02-15 22:41 ` Richard W.M. Jones
2019-02-15 22:53   ` Richard W.M. Jones
2019-02-16  8:16     ` Wouter Verhelst
2019-02-15 22:55   ` Pavel Machek
2019-11-17 16:58   ` Richard W.M. Jones
2019-02-17  8:44 ` Richard W.M. Jones
2019-02-17 23:15   ` Pavel Machek [this message]
2019-02-17 23:51     ` Richard W.M. Jones
     [not found]       ` <CAM1OiDOKJ3SGHABNooQPFfx3KMYepYmSPxwyZZjZERc_y9v1WA@mail.gmail.com>
2019-03-12 16:14         ` Shaun McDowell
2019-03-12 16:14           ` Shaun McDowell

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=20190217231514.GA10675@amd \
    --to=pavel@ucw.cz \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjones@redhat.com \
    --cc=smcdowell@cloudbd.io \
    /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.