From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phillip Susi Subject: Re: Tracking actual disk write sources instead of flush thread Date: Wed, 23 Apr 2014 15:39:19 -0400 Message-ID: <535816E7.2070106@ubuntu.com> References: <534DE477.5080904@ubuntu.com> <20140416140147.GA15429@linux.intel.com> <534E9E9D.5030600@ubuntu.com> <4C30833E5CDF444D84D942543DF65BDA625F51A9@G4W3303.americas.hpqcorp.net> <534EC964.6080702@ubuntu.com> <4C30833E5CDF444D84D942543DF65BDA625F5246@G4W3303.americas.hpqcorp.net> <534ED9B8.9090605@ubuntu.com> <20140423134805.GB13050@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Zuckerman, Boris" , "linux-fsdevel@vger.kernel.org" To: Matthew Wilcox Return-path: Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.230]:32099 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751908AbaDWTqX (ORCPT ); Wed, 23 Apr 2014 15:46:23 -0400 In-Reply-To: <20140423134805.GB13050@linux.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: -----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-----