Date: Thu, 17 May 2001 00:11:05 +0200 From: Tor.Egge@fast.no To: dillon@earth.backplane.com Cc: arch@FreeBSD.ORG Subject: Re: on load control / process swapping Message-ID: <200105162211.AAA02889@midten.fast.no> In-Reply-To: Your message of "Wed, 16 May 2001 14:35:39 -0700 (PDT)" References: <200105162135.f4GLZdo78984@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Question number 2. You have this: > > error = cluster_read(vp, ip->i_size, lbn, > - size, NOCRED, uio->uio_resid, seqcount, &bp); > + size, NOCRED, blkoffset + uio->uio_resid, seqcount, &bp); > > > What is the blkoffset adjustment for? Is that a bug fix for something > else? lbn doesn't reflect the least significant bits in uio->uio_offset, causing too small readahead. Adding blkoffset to uio->uio_resid compensates for that. > In anycase, in regards to the main patch. Why don't I commit > the header file support pieces from your patch with some minor > alignment cleanups to the struct file, but leave your > rawread/rawwrite out until we can make it work properly. Fine. > Then I can use IO_NOBUFFER to cause the underlying VM pages to > be freed (the underlying struct buf is already released in the > existing code). The result will be the same low-VM-page-cache > impact as your rawread/rawwrite code except for the extra buffer > copy. I think I can reach about 90% of the performance you get > simply by freeing the underlying VM pages because this will > allow them to be reused in the next read(), and they will > already be in the L2 cache. If I don't free the underlying VM > pages the sequential read will force the L2 cache to cycle, and > I'll bet that is why you get such drastically different idle > times. Avoiding that copyout() is the major reason for increased idle time. The L2 cache will still cycle a lot with your suggested implementation for the load I used since the normal amount of outstanding IO is 25 MB (256 KB x 100). The L2 cache is a lot smaller then 25 MB. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105162211.AAA02889>