From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13385 invoked by alias); 20 Dec 2013 08:21:03 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 13361 invoked by uid 89); 20 Dec 2013 08:21:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FSL_HELO_FAKE,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ee0-f50.google.com Received: from mail-ee0-f50.google.com (HELO mail-ee0-f50.google.com) (74.125.83.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 20 Dec 2013 08:21:01 +0000 Received: by mail-ee0-f50.google.com with SMTP id c41so896980eek.9 for ; Fri, 20 Dec 2013 00:20:58 -0800 (PST) X-Received: by 10.15.52.197 with SMTP id p45mr1298946eew.98.1387527658741; Fri, 20 Dec 2013 00:20:58 -0800 (PST) Received: from gmail.com (BC24D856.catv.pool.telekom.hu. [188.36.216.86]) by mx.google.com with ESMTPSA id a45sm16371960eem.6.2013.12.20.00.20.57 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Dec 2013 00:20:58 -0800 (PST) Date: Fri, 20 Dec 2013 08:21:00 -0000 From: Ingo Molnar To: Masami Hiramatsu Cc: "Frank Ch. Eigler" , linux-arch@vger.kernel.org, Ananth N Mavinakayanahalli , Sandeepa Prabhu , x86@kernel.org, lkml , "Steven Rostedt (Red Hat)" , systemtap@sourceware.org, "David S. Miller" Subject: Re: [PATCH -tip v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs Message-ID: <20131220082056.GA15934@gmail.com> References: <20131219090353.14309.15496.stgit@kbuild-fedora.novalocal> <52B3C5E6.2040802@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52B3C5E6.2040802@hitachi.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-q4/txt/msg00458.txt.bz2 * Masami Hiramatsu wrote: > > But a closer look indicates that the insertion of kprobes is > > taking about three (!!) orders of magnitude longer than before, as > > judged by the rate of increase of 'wc -l > > /sys/kernel/debug/kprobes/list'. > > Right, because kprobes are not designed for thousands of probes. Then this needs to be fixed, because right now this bug is making it near impossible to properly test kprobes robustness. For example a hash table (hashed by probe address) could be used in addition to the list, to speed up basic operations. Thanks, Ingo