Re: [PATCH 0/3] writeback visibility

[Michael Rubin]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/