async-io for reads & writes

--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

On 7 May 98, at 15:07, Stewart Forster <slf@connect.com.au> wrote:

> In investigating why our caches (1.2beat20) get occasional warnings
> about the ASYNC queue filling up under heavy load, I discovered that a lot
> of the warnings had to do with open's, read's and write's all to the same
> store directory, ie. there was an imbalance happening. A single cache store
> directory was getting all the load, blowing out service times and causing
> ASYNC disk IO requests to bank up to the point of causing warnings.

 While looking at how much time it takes for squid to make read's, write's
 I wanted to ask, why we do writes in async io? write calls with select takes
 0.2 mSec on average - its almost only process-to-os-buffers transfers, I think.
 Is there something I do not see that makes it efficient to spawn a thread for
 such writes?

 I sure agree that anything that might block for prolongued time would
 benefit from async-io, but disk io that can wait in select - why that?

 I'm wondering if it just only adds context switches and in the end does
 exactly the same as select-based writes - moves user-buffers to os-buffers.

 Select-based writes have the advantage that when OS buffers are full, select
 would not report ready-for-write FD's, while with threads we have to cope
 with blowing request-queues.

 I think that its almost same with read's. If OS reports to select that you
 can read from given FD, then its almost sure that some part of data is already
 inside OS buffers, so using threads for reading that data gives little, IMHO.

 am i missing something?

 ----------------------------------------------------------------------
  Andres Kroonmaa mail: andre@online.ee
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
 ----------------------------------------------------------------------

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:49 MDT