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