From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:60608 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727312AbeKHCCk (ORCPT ); Wed, 7 Nov 2018 21:02:40 -0500 Subject: Re: [PATCH] fs/proc: introduce /proc/stat2 file To: Davidlohr Bueso , Andrew Morton Cc: Daniel Colascione , linux-fsdevel@vger.kernel.org, linux-kernel , Davidlohr Bueso References: <20181029192521.23059-1-dave@stgolabs.net> <20181106154840.3b448356214afa63dc8cb28c@linux-foundation.org> <20181107033234.djng6kas4tjkevln@linux-r8p5> From: Waiman Long Message-ID: <04dc1bc2-8abb-c18b-ffc8-0e96bf9858a0@redhat.com> Date: Wed, 7 Nov 2018 11:31:33 -0500 MIME-Version: 1.0 In-Reply-To: <20181107033234.djng6kas4tjkevln@linux-r8p5> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 11/06/2018 10:32 PM, Davidlohr Bueso wrote: > On Tue, 06 Nov 2018, Andrew Morton wrote: > >> It would be interesting to know precisely which stat fields the >> database-which-shall-not-be-named is looking for.  Then we could cook >> up a very whizzy way of getting at the info. > > The ctxt field, afaik. In any case they have been able to work around > the bottleneck. I'm not sure if that is the case for Waiman, however. > In my case, the customers just complain about the slowdown in reading /proc/stat on some platforms vs. the others because some had many more interrupt lines than the others. They didn't specifically call out what they were looking at. >> >> A downside of the stat2 approach is that applications will need to be >> rebuilt.  And hopefully when people do this, they'll open >> "/etc/my-app-name/symlink-to-proc-stat" (or use per-application config) >> so they won't need a rebuild when we add /proc/stat3! >> >> A /proc/change-how-stat-works tunable would avoid the need to rebuild >> applications.  But if a system still has some applications which want >> the irq info then that doesn't work. >> >> It's all very sad, really. >> >> btw, >> >>> +The stat2 file acts as a performance alternative to /proc/stat for >>> workloads >>> +and systems that care and are under heavy irq load. In order to to >>> be completely >>> +compatible, /proc/stat and /proc/stat2 are identical with the >>> exception that the >>> +later will show 0 for any (hard)irq-related fields. This refers >>> particularly >> >> "latter" >> >>> +to the "intr" line and 'irq' column for that aggregate in the cpu >>> line. >> >> btw2, please quantify "poor performance".  That helps us determine how >> much we care about all of this! > > Up to a quarter of a second is what was reported as being spent every > time > /proc/stat is used. This is with 1k cores and 4k interrupts. > > Thanks, > Davidlohr Yes, the time spent will scale more or less linearly with the # of cores and # of interrupts. Thanks, Longman