Date: Thu, 14 Jan 2010 18:56:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: alc@freebsd.org, Peter Jeremy <peterjeremy@optushome.com.au>, stable@freebsd.org Subject: Re: An old gripe: Reading via mmap stinks Message-ID: <201001150256.o0F2ucOx080837@apollo.backplane.com> References: <200603232352.k2NNqPS8018729@gate.bitblocks.com> <200603241518.01027.mi%2Bmx@aldan.algebra.com> <20060325103927.GE703@turion.vk2pj.dyndns.org> <200603250920.14208@aldan> <20060325190333.GD7001@funkthat.com> <4B4F7CF5.4040307@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: mmap: 43.400u 9.439s 2:35.19 34.0% 16+184k 0+0io 106994pf+0w : read: 41.358u 23.799s 2:12.04 49.3% 16+177k 67677+0io 0pf+0w : :Observe, that even though read-ing is quite taxing on the kernel (high :sys-time), the mmap-ing loses overall -- at least, on an otherwise idle :system -- because read gets the full throughput of the drive (systat -vm :shows 100% disk utilization), while pagefaulting gets only about 69%. : :When I last brought this up in 2006, it was "revealed", that read(2) :uses heuristics to perform a read-ahead. Why can't the pagefaulting-in :implementation use the same or similar "trickery" was never explained... Well, the VM system does do read-ahead, but clearly the pipelining is not working properly because if it were then either the cpu or the disk would be pegged, and neither is. It's broken in DFly too. Both FreeBSD and DragonFly use vnode_pager_generic_getpages() (UFS's ffs_getpages() just calls the generic) which means (typically) the whole thing devolves into a UIO_NOCOPY VOP_READ(). The VOP_READ should be doing read-ahead based on the sequential access heuristic but I already see issues in both implementations of vnode_pager_generic_getpages() where it finds a valid page from an earlier read-ahead and stops (failing to issue any new read-aheads because it fails to issue a new UIO_NOCOPY VOP_READ... doh!). This would explain why the performance is not as bad as linux but is not as good as a properly pipelined case. I'll play with it some in DFly and I'm sure the FreeBSD folks can fix it in FreeBSD. -Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001150256.o0F2ucOx080837>