> 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. > Well I don't think queue rearrangement is even in the picture, that's not the flusher thread's job? The starvation I was actually referring to was from http://lwn.net/Articles/326552/ : which says that pdflush threads are non-blocking meaning if the queue is congested, they don't block, they just move on. This is because they have to address many queues at the same time. If other applications continue keeping the queue congested, then pdflush just keeps going in circles (as it is non-blocking) and hence will be "starved" of access to the queue. On the other hand per-bdi flusher threads can block for a slot in the request queue because they are per block device and hence can perform better in congestion situations. Any comments are welcome. Thanks, -Joel -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
