Kevin Littlejohn wrote:
> Have started the work to create a shared interface - am coding to the
> programmer's guide and the existing interfaces. Note here, aufs currently has
> a horrible "single request pool across the entire system" thing going, which
> I'll be breaking up into one request queue per cache dir. That has some other
> ramifications - it means per-cache-dir load readings will work, but it also
> may do bad things number-of-thread-wise - I may have to fall back to one
> thread per fs, which makes sense to me anyway (correct me if I'm wrong, but
> that thread will be blocking on disk io, another thread won't gain us
> anything, right?).
You will need a pool of threads per FS for best performance. Multiple
parallell random I/O requests are better optimized by the OS than random
time-sequential ones..
> Oh, I need to check something, tho: The aufs request_queue2 setup,
> is that a good thing(tm)?
The "request_queue2" thingy is where async-io temporarily puts requests
waiting for the queue lock to be freed (currently held by one of the I/O
threads). It gets triggered from time to time on high I/O load.
/Henrik
Received on Sat Mar 17 2001 - 06:28:11 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:38 MST