Re: Tracking actual disk write sources instead of flush thread

[Matthew Wilcox <willy@linux.intel.com>]

On Wed, Apr 16, 2014 at 03:27:52PM -0400, Phillip Susi wrote:
> On 4/16/2014 2:28 PM, Zuckerman, Boris wrote:
> > [bz:] In such case I'd rather have lighter implementation of
> > caching layer, than ability to track disk IOs per process. IOs per
> > process can be tracked by other tools...
> 
> What other tools?
> 
> I can envision blktrace being extended to hook into the mm layer to
> track the real source of writes, but without any overhead when the
> trace is not running.

How do you 'envision' this zero-overhead trace, exactly?

I don't understand your high-level goal, which makes suggesting
low-overhead solutions hard.  Can you tolerate a certain amount of
ambiguity, for example?  Do you really only want to track back to the
UID that is causing the I/O?  With shared mmaps, are you OK attributing
the I/O to one of the processes that has written to it, or do you need to
attribute the write to all the processes that have written to that page?

You're coming off kind of condescending, which isn't a great approach
when you're asking for a new feature to be implemented.