PQ_LAUNDRY

[Gary Jennejohn]

On Sun, 6 Nov 2016 09:12:30 +0100
Gary Jennejohn <gljennjohn at gmail.com> wrote:

> On Sat, 5 Nov 2016 10:41:48 -0700
> Mark Johnston <markj at FreeBSD.org> wrote:
> 
> > On Sat, Nov 05, 2016 at 10:31:28AM +0100, Gary Jennejohn wrote:  
> > > On Thu, 3 Nov 2016 11:29:16 -0700
> > > Mark Johnston <markj at FreeBSD.org> wrote:    
> > > > Some more details and the diff for PQ_LAUNDRY can be viewed here:
> > > > https://reviews.freebsd.org/D8302
> > > > 
> > > > We would like to commit it next week. Any additional comments, review,
> > > > or testing would be welcome.
> > > >    
> > > 
> > > In my use case, which is moving multi-gigabyte video files from
> > > one file system to another, this seems to swap more than the
> > > previous code did.  Moving such large files with the previous
> > > code seemed to recycle Inact more quickly and IIRC only a few 10s
> > > of MB were swapped out.  In my test this morning 125MB were
> > > swapped out and Inact was not recycled as quickly.  The overall
> > > size of the files moved was about the same in the two tests.    
> > 
> > Are you computing the amount swapped out as the amount of memory swapped
> > out minus the amount of swapins? Or is 125MB the amount of swap used
> > after the test? Output from "sysctl vm.stats" taken before and after any
> > test on both HEAD on PQ_LAUNDRY would be most useful.
> >   
> 
> 125MB was the swap value showed by top after the files had all been
> mv'd.  But fairly soon after completion a few MB were swapped back in.
> 

OK, on a level playing field there's no difference between the old and
the new code.  In fact, according to top the old code swapped out 272K
and the new code swapped out 220K.  An insignificant difference.

The test scenario was as follows:
1) boot the box
2) start X
3) mount the source directory
4) start a bash script which copied the same set of files in a for-loop
5) start top and observe what happens

Since all the files were either 4.3GB or 2GB cp didn't use mmap, but
rather did read/write in a loop (if the comment in utils.c is still valid).

My test yesterday did a `mv *`, but since mv used fastcopy(), which
also does read/write in a loop, the pressure on the vm should have
been very similar to cp.

The major difference between today and yesterday was that I'd been
running firefox and claws-mail for hours when I started the mv, so
there was something to swap out.

Since I'm not too eager to noodle around for hours before starting
a test, let's just say that the new code appears to be no worse, or
perhaps even better, than the old code.

-- 
Gary Jennejohn