Re: Tracking actual disk write sources instead of flush thread

[Phillip Susi <psusi@ubuntu.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/23/2014 9:48 AM, Matthew Wilcox wrote:
> How do you 'envision' this zero-overhead trace, exactly?

The same way blktrace currently works: the accounting code is not run
until enabled.  When disabled, nothing more runs than does now.
Obviously while actively tracing, there would be overhead.

> 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?

I suppose the first process that dirties the page would be fine.  It
isn't very often that more than one process is writing to the same
data at the same time.

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

I'm just a little flabbergasted that this regression ( I'm sure there
was a time when the current io accounting mechanism did work, probably
before the buffer_head -> page cache transition way, *way* back when )
went unfixed for so long, especially when it is kind of a vital tool
for a sysadmin trying to figure out why his system is slow.  I think
every sysadmin out there takes it for granted that running iotop
should let them spot what process or processes are the source of all
the IO, so I almost can't believe that it doesn't really work.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWBbnAAoJEI5FoCIzSKrwJaUH/RG3kn8pDxtoqvijAZj6BgnT
iuI/ptnFhaYo22p3coRggqYHKI0Nu6MmNJx9Iq2g6lfoFTCY02Bb9fZ9r05Svg5h
pQaLvk0dsK1vNwYTHW573KkMiyeUTvi7nUeRUB9MTarhHO6HveqvENd/jEiviCE4
zOqyT15V9Riwm78L5ytQFNsq43wNtZ4d9MUmw0182f/IRtpHn/G1B0UroqjZgs/+
a5hIudxajar5oVfR6O0A7+guKkJa4b8ibUHns4zgbEo1HbO7taOcn6rNoNV/C3NK
lN5/0lcHNZwvk0JN9diiEP4812KWZyJIFm7E8FlvchkXNCeHG5hNHjg7FUB1t30=
=Cgep
-----END PGP SIGNATURE-----