Date: Fri, 06 Jun 2008 03:25:54 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Kirk Strauser <kirk@strauser.com> Cc: freebsd-questions@freebsd.org Subject: Re: Poor read() performance, and I can't profile it Message-ID: <48489222.7020501@FreeBSD.org> In-Reply-To: <4848757B.30408@strauser.com> References: <200806051508.29424.kirk@strauser.com> <4848523E.2010604@FreeBSD.org> <200806051617.54400.kirk@strauser.com> <484867E3.3070705@FreeBSD.org> <4848757B.30408@strauser.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk Strauser wrote: > Kris Kennaway wrote: > >> No, if it's reading in 16 byte units it will explain the terrible >> performance. > > No, it's actually doing 4096-byte reads. That was just an example of > what I meant. I don't understand what you meant by "It's also doing a lot of lseek()s to what is likely the current position anyway (example: seek to 0x00, read 16 bytes, seek to 0x10, etc.)." then. Please show a typical part of the ktrace output. Kris > Since I wrote that, though, I wrote a program to do > 1,000,000 seeks to position 0, and it ran immeasurably fast. I'm > guessing that lseek() is optimized to not do anything if you ask it to > move to the position you're already at. > > Any other thoughts? There definitely aren't any setbuf() calls, and no > matter what it still takes 100 times more kernel overhead on Linux than > FreeBSD. Speaking of which, I think my next experiment will be to try > the Linux binaries on FreeBSD and see if it behaves similarly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48489222.7020501>