Hi On Tue, Oct 20, 2009 at 12:07 PM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote: > 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. OK, here is my follow up thoughts: However, about "spindle", I still think this is specificly mean to hard drive. "Slow" remote filesystem like NFS could still gain advantage using the pdflush approach since it will utilize the whole network bandwith available to our host. The ultimate way to see which one is better is by doing benchmark, of course -- 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
