On Mon, 12 Jul 2010 23:52:39 +0800 Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: > > Also, I'd prefer that the > > comments remain somewhat more descriptive of the circumstances that > > we are operating under. Comments like "retry later to avoid blocking > > writeback of other inodes" is far, far better than "retry later" > > because it has "why" component that explains the reason for the > > logic. You may remember why, but I sure won't in a few months time.... me2 (of course). This code is waaaay too complex to be scrimping on comments. > Ah yes the comment is too simple. However the redirty_tail() is not to > avoid blocking writeback of other inodes, but to avoid eating 100% CPU > on busy retrying a dirty inode/page that cannot perform writeback for > a while. (In theory redirty_tail() can still busy retry though, when > there is only one single dirty inode.) So how about > > /* > * somehow blocked: avoid busy retrying > */ That's much too short. Expand on the "somehow" - provide an example, describe the common/expected cause. Fully explain what the "busy" retry _is_ and how it can come about. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
