: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>

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

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

[...]
> 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)?

During testing drive with dd I noticed that there are serious performance 
problems. Programs which need disk access, block for 10 and more seconds. 
Sometimes they don't continue the work until dd is finished. Raw disk access 
(ie not writing to file, but directly to the disk) is reported to be OK (I 
can't test it myself).

All tests are done with this command:
dd if=/dev/zero of=./file bs=4096k count=1000

Syncing after each dd helps to reproduce it more reliably (cache?).

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

And as a side effect - I can't get my network interfaces up any more after 
running dd - "em0: Could not setup receive strucutres".