Unmapped buffers: to be merged in several days

[Konstantin Belousov]

On Tue, Mar 12, 2013 at 06:32:33PM -0600, Ian Lepore wrote:
> I tested this for armv4 today, and it works.  I had a (bogus)
> used-before-init warning from gcc, and I had to add a couple lines of
> code to the pmap_copy_pages() to increment some variables; patch
> attached.  I think the pmap-v6 routine needs the same change, but I
> didn't get as far as testing v6 yet.  
> 
> I tested with both the md and ahci drivers on armv4.  Peformance seemed
> to be about the same before and after based on some crude tests such as
> "time tar -cf - /mnt >/dev/null" where I had the ahci drive (a fast ssd
> with a few hundred MB of data on ufs) mounted on /mnt.
> 
> I don't have a v6 board with a sata interface running yet, but I can
> test with md, hopefully I'll get to it tomorrow.
> 
> -- Ian
> 

> Minimal changes required to get umapped.17 to build and run.
> 
> diff -r 179fcc6b2485 -r 2f1c61450df0 sys/arm/arm/pmap.c
> --- a/sys/arm/arm/pmap.c	Tue Mar 12 13:41:10 2013 -0600
> +++ b/sys/arm/arm/pmap.c	Tue Mar 12 13:45:34 2013 -0600
> @@ -4458,6 +4458,9 @@ pmap_copy_pages(vm_page_t ma[], vm_offse
>  		pmap_copy_page_offs_func(VM_PAGE_TO_PHYS(a_pg), a_pg_offset,
>  		    VM_PAGE_TO_PHYS(b_pg), b_pg_offset, cnt);
>  #endif
> +		xfersize -= cnt;
> +		a_offset += cnt;
> +		b_offset += cnt;
>  	}
>  }
>  
> diff -r 179fcc6b2485 -r 2f1c61450df0 sys/dev/md/md.c
> --- a/sys/dev/md/md.c	Tue Mar 12 13:41:10 2013 -0600
> +++ b/sys/dev/md/md.c	Tue Mar 12 13:45:34 2013 -0600
> @@ -753,9 +753,10 @@ mdstart_vnode(struct md_s *sc, struct bi
>  
>  	KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd",
>  	    (uintmax_t)bp->bio_length));
> -	if ((bp->bio_flags & BIO_UNMAPPED) == 0)
> +	if ((bp->bio_flags & BIO_UNMAPPED) == 0) {
> +		pb = NULL;
>  		aiov.iov_base = bp->bio_data;
> -	else {
> +	} else {
>  		pb = getpbuf(&md_vnode_pbuf_freecnt);
>  		pmap_qenter((vm_offset_t)pb->b_data, bp->bio_ma, bp->bio_ma_n);
>  		aiov.iov_base = (void *)((vm_offset_t)pb->b_data +

Both are applied, thank you, arm change is needed for pmap-v6.c as well,
definitely.

I do not expect to see much, if any, change in the system time on the
single-core machines, esp. on the memory-starved configurations.

What you could try to measure to get the targeted test, is to calculate
the sha1 of some large file which still fits into the RAM, but causes
the buffer cache trashing. E.g., on my workstation with 12GB of RAM
and 1.2GB of buffer cache space, I would take 10GB file and measure
the time to sha1 it, 4 times. First run is to load the pages into cache,
ignore the first run timings. Next 3 runs give you the data for ministat(1),
for patched and for stock kernels.

On 4x core/HTT sandy bridge machine, I see 30% reduction of the system
time in the described test. For single-core, the difference should be
much less, if any.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130313/25b0f1f7/attachment.sig>