From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB49DC433E0 for ; Fri, 29 May 2020 08:20:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A96B52065C for ; Fri, 29 May 2020 08:20:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="dMPyFgen" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A96B52065C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 28725800BA; Fri, 29 May 2020 04:20:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2362F80010; Fri, 29 May 2020 04:20:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FEB7800BA; Fri, 29 May 2020 04:20:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id E8CA880010 for ; Fri, 29 May 2020 04:20:29 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A67F4181AEF1E for ; Fri, 29 May 2020 08:20:29 +0000 (UTC) X-FDA: 76869059778.10.ghost55_3e76fadf6603c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 8713A16A0D1 for ; Fri, 29 May 2020 08:20:29 +0000 (UTC) X-HE-Tag: ghost55_3e76fadf6603c X-Filterd-Recvd-Size: 5712 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Fri, 29 May 2020 08:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=B4/WN5at4WCK3sH69xp6uhuoftjoGDULyq3fGJTaL/k=; b=dMPyFgenjTwA5s4nWdDEbhBXgB ueanJlZuj6XX+oOZJ4jsBE9zahjMbxayoUS9g0jBXiFHjuIg7hJvMJPNuhbCEU+Qd9WQhh+TJ/bUt Y3HBu9OEJ2epUzPVI7hOHbmCIv6BKTIiCrO9CRiUOFs+fFIWDmtA7Bi3XIrOThiz1nwNo88oPtW6h 9WQ49tX27Iol6t0TJB54SQAMNlu34m4GktZkxz/366CqmpR8z/5ugzVZ2YZg4sjyE/N1cHZfuFp/V Poa7L2vWNRk8vkBM9rFcFENwPQvET7zAU2mun4X/77exQVNzBoOr8h+VJy1zMdAGsspmYi5//s28X Kb67eb1Q==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jea5f-0000X2-Ce; Fri, 29 May 2020 08:10:07 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id A69E630280F; Fri, 29 May 2020 10:09:57 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 65A60203B84B9; Fri, 29 May 2020 10:09:57 +0200 (CEST) Date: Fri, 29 May 2020 10:09:57 +0200 From: Peter Zijlstra To: Axel Rasmussen Cc: Steven Rostedt , Andrew Morton , David Rientjes , Davidlohr Bueso , Ingo Molnar , Ingo Molnar , Jerome Glisse , Laurent Dufour , "Liam R . Howlett" , Matthew Wilcox , Michel Lespinasse , Vlastimil Babka , Will Deacon , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, AKASHI Takahiro , Aleksa Sarai , Alexander Potapenko , Alexey Dobriyan , Al Viro , Andrei Vagin , Ard Biesheuvel , Brendan Higgins , chenqiwu , Christian Brauner , Christian Kellner , Corentin Labbe , Daniel Jordan , Dan Williams , David Gow , "David S. Miller" , "Dmitry V. Levin" , "Eric W. Biederman" , Eugene Syromiatnikov , Jamie Liu , Jason Gunthorpe , John Garry , John Hubbard , Jonathan Adams , Junaid Shahid , Kees Cook , "Kirill A. Shutemov" , Konstantin Khlebnikov , Krzysztof Kozlowski , Mark Rutland , Masahiro Yamada , Masami Hiramatsu , Mathieu Desnoyers , Michal Hocko , Mikhail Zaslonko , Petr Mladek , Ralph Campbell , Randy Dunlap , Roman Gushchin , Shakeel Butt , Tal Gilboa , Thomas Gleixner , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Vincenzo Frascino , Yang Shi , Yu Zhao , Tom Zanussi Subject: Re: [PATCH v2 0/7] Add histogram measuring mmap_lock contention latency Message-ID: <20200529080957.GI706495@hirez.programming.kicks-ass.net> References: <20200528235238.74233-1-axelrasmussen@google.com> <20200528202435.65396221@oasis.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8713A16A0D1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 28, 2020 at 06:39:08PM -0700, Axel Rasmussen wrote: > The use case we have in mind for this is to enable this instrumentation > widely in Google's production fleet. Internally, we have a userspace thing > which scrapes these metrics and publishes them such that we can look at > aggregate metrics across our fleet. The thinking is that mechanisms like > lockdep or getting histograms with e.g. BPF attached to the tracepoint > introduces too much overhead for this to be viable. (Although, granted, I > don't have benchmarks to prove this - if there's skepticism, I can produce > such a thing - or prove myself wrong and rethink my approach. :) ) Whichever way around; I don't believe in special instrumentation like this. We'll grow a thousand separate pieces of crap if we go this route. Next on, someone will come and instrument yet another lock, with yet another 1000 lines of gunk. Why can't you kprobe the mmap_lock things and use ftrace histograms?