Hi... On Mon, Oct 19, 2009 at 12:57 AM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote: > Hi Rik, Peter, > > Thanks for sharing! Peter, I think spindle is used just as another > word for slow device which I guess could be any other type of slow > storage medium like iSCSI or loop over NFS. In some degree, I agree with that. However, specificly to block device like hard disk, where things could made difference i.e doing read back and forth would slow things down instead of keep moving the disk head forward, I think what Jens Axboe mean is specific to hard disk with disk head (pleaeCMIIW if I use wrong term) > But I have a question with the per-bdi writeout, how does it solve the > problem of request starvation, Wont the writeback threads be starved > anyway if users kept writing to the device? IMO yes, but "starved" better :) Not sure if I write it correctly, but here is my understanding: say you have 4 pdflush threads, competing to write to a disk. All are busy, so you can say all are quite starved. But the writing process (even though it's using async style) doesn't know about it. All it knows, it sucessfully put the write request at the head of the queue, but somehow something is starving it. Not to mention the context switching cost between pdflush threads. With per-bdi flusher, the problem is at least reduced. Now all request submitter are concentrated to one worker. This worker will arrange the queue the best it can, and the submitter IMO will know whether it is coming late (and consequently served after its predecessor) or it is coming when the queue is relatively empty. And, no more context switching between pdflush just to find all the threads are busy. With my lousy knowledge about block device, that's the best I can share :) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
