DragonFlyBSD

[...]

There is one more strange thing in running these tests. I looked at memory
stats in top before and after running dd.

Before:
Mem: 42M Active, 40M Inact, 95M Wired, 304K Cache, 53M Buf, 795M Free
After:
Mem: 70M Active, 679M Inact, 175M Wired, 47M Cache, 109M Buf, 1752K Free

FWIW, I observe similar figures. I also noticed that deleting ./file
and waiting a bit restores memory to the "before" state.

The size increase in the wired pool can be reproduced more simply with:

sysctl vm.stats.vm.v_wire_count # A
dd if=/dev/zero of=./file bs=4096k count=1
sysctl vm.stats.vm.v_wire_count # B
rm ./file
sysctl vm.stats.vm.v_wire_count # C

A C && B A + 1

I traced this with gdb. The additional wired page is part of a struct
buf (b_xio) instance tied to the ./file vnode. I reckon this vnode
stays cached (namecache?) when the dd process ends and deleting ./file
forces destruction of the vnode.

AFAIU wired pages can not be reclaimed by the pager when memory is
low. So is it normal to keep b_xio pages wired when they are "just"
cached in a vnode (i.e. no ongoing r/w operation)?

Oops. I've just noticed that block size is 4096k in the original post
and not 4096. I did all my experiments with the latter (there is a
paste bug in my previous email).

I can confirm that creating a 4MB file consumes 1026 wired pages.

So either this is a) insane b) a bug or c) a counting issue, where the
buffer cache gets placed with the wired pages.

I didn't yet look at the code, but does this mean that additionally to
the buffer cache data, this b_xio is kept as well, keeping the same data?

cheers
simon

:I can confirm that creating a 4MB file consumes 1026 wired pages.
:
:So either this is a) insane b) a bug or c) a counting issue, where the
:buffer cache gets placed with the wired pages.

They're just wired because they're in the buffer cache.  The real issue
    here is buffer cache management, that's all.

:>> I traced this with gdb. The additional wired page is part of a struct=
:
:>> buf (b_xio) instance tied to the ./file vnode. I reckon this vnode
:>> stays cached (namecache?) when the dd process ends and deleting ./file=
:
:>> forces destruction of the vnode.
:
:I didn't yet look at the code, but does this mean that additionally to
:the buffer cache data, this b_xio is kept as well, keeping the same dat=
:a?
:
:cheers
: simon

No, the b_xio is part of the struct buf.  The pages are wired only once.

This is really just a buffer cache management issue.  There's no reason
    the pages have to remain wired that long... the related buffer can
    certainly be destroyed after having been flushed to disk under heavy-load
    situations while still leaving the backing VM pages intact in the VM
    page cache.  I would focus any fixes in that area.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On 2014-02-18 14:47, bugtracker-admin@leaf.dragonflybsd.org wrote:

I don't see the high usage corecode showed in his test.

Matt, there was a ton of work in the VM subsystem, is it possible that
this is not the case anymore?

Well, we most definitely have quite bad problems under heavy I/O load.
Interactive performance drops significantly. Getting BFQ or similar
dsched policy up to scratch would go a long way here.

Cheers,
Alex