Date: Fri, 21 Dec 2007 00:36:40 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: ticso@cicely.de Cc: freebsd-fs@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: readv: parallel or sequential? Message-ID: <200712210036.49040.peter.schuller@infidyne.com> In-Reply-To: <20071220221735.GB67140@cicely12.cicely.de> References: <fjbb3v$n60$1@ger.gmane.org> <200712202140.08367.peter.schuller@infidyne.com> <20071220221735.GB67140@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2867901.o7Q3KWBikV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > In case the application uses serialized access there is not much to do > beside preread or caching writes to make use of multiple spindles. Agreed. > But an application has to be carefull, because parallel access within > a single file almost always mean that access is not linear anymore, so > many opther performance tunings won't work as good as they could, so > this could easily outweight the performance gain from multiple access. =46or seek bound applications you don't really care anyway. If you have a=20 mixture of stream bound and seak bound I/O going on you will run into vario= us=20 issues which are difficult to avoid without very careful application-specif= ic=20 tuning I think. But for the simple case of doing concurrent seek-bound I/O = I=20 would expect it to be handled gracefully by the OS. And I do mean to the same file, rather than file descriptor (in response to= =20 the other post on descriptors). > Nonlinear access from within an application has to be for another reason > and not as a performance tuning. Why? Again, PostgreSQL, other databases, or any file access pattern which i= s=20 seek bound stands to gain more or less linearly from concurrent I/O being=20 propagated to constituent devices in a non-serialized fashion. This is a=20 pretty basic assumption in my book when designing an application. Whenever= =20 something is seek bound, assuming I have concurrency in my app, I look at t= he=20 number of constituent devices on the device and the type of RAID or similar= =20 being used (including stripe sizes in relation to the size of my I/O=20 requests, etc). I fully expect to be able to scale linearly with the number of underlying=20 devices, assuming raid0/raid10 or something equivalent, and assuming I have= a=20 concurrency that is sufficiently high to keep all drives busy. (There are valid exceptions of course, such as raidz/raidz2. But that's bey= ond=20 the scope of this discussion.) =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart2867901.o7Q3KWBikV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHavyQDNor2+l1i30RAn9BAJ4ookJhNAFYuq2ft6B+Gb2TcU4wKgCeI6mI /9J8DnwEekbyfZcTLUEO/+Y= =P/2n -----END PGP SIGNATURE----- --nextPart2867901.o7Q3KWBikV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712210036.49040.peter.schuller>