On Wed, Jun 23, 2010 at 5:02 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > I don't see any probems with these stats - no matter the > implementation, they'll still be relevant. Cool. I have a new patch I will send out tomorrow for these. They have been moved to /proc/sys/vm too as Christoph recommended. Makes more sense too. > I'd much prefer all the bdi stats in the one spot. It's hard enough > to find what you're looking for without splitting them into multiple > locations. Yeah I hear ya. > The other thing to consider is that tracing requires debugfѕ to be > mounted. Hence most kernels are going to have the debug stats > available, anyway.... This thread has made me reconsider pursuing if there is a way that we can access debugfs safely in our environment. It would make things a lot easier. >> >> writeback: tracking subsystems causing writeback > I don't see much value in exposing this information outside of > development environments. I think it's much better to add trace > points for events like this so that we do fine-grained analysis of > when the events occur during problematic workloads.... > These stats aren't the place for observing that a disk is bad ;) They do help grant visibility in the whole stack of behaviour. Writeback has created a whole lot of confusion and time waste. I do agree with you that these should be folded into tracing infrastructure. > Yes, I hear this all the time from appliance developers that cache > everything they need in userspace - they just want the kernel to > stay out of the way and not use the unused RAM for caching stuff that > doesn't matter to the application. Normally the issue is unbounded > growth of the inode and dentry caches, but I can see how exceeding > writeback limits can be just as much of a problem. You hit the nail on the head. There's nothing like writing back logs to create latency spikes for direct IO traffic that make folks scratch their heads. In low memory environments this can get more confusing for a appliance developers trying to find out what happened after the fact. Thanks again. I think (or hope) the next set of patches will be more applicable. mrubin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href