From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751254AbdANEaZ (ORCPT ); Fri, 13 Jan 2017 23:30:25 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:35154 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbdANEaY (ORCPT ); Fri, 13 Jan 2017 23:30:24 -0500 Date: Sat, 14 Jan 2017 13:20:00 +0900 From: Namhyung Kim To: Steven Rostedt Cc: LKML , Ingo Molnar Subject: Re: [RFC/PATCH] ftrace: Allow to change size of function graph filters Message-ID: <20170114042000.GA1735@danjae.aot.lge.com> References: <20170113042243.15259-1-namhyung@kernel.org> <20170113111618.53709bf8@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170113111618.53709bf8@gandalf.local.home> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steve, On Fri, Jan 13, 2017 at 11:16:18AM -0500, Steven Rostedt wrote: > On Fri, 13 Jan 2017 13:22:43 +0900 > Namhyung Kim wrote: > > > It's currently fixed to 32 and it ignores when user gives a pattern > > which match to functions more than the size. So filtering like all > > system calls or many functions with common prefix cannot be set all. > > Not sure this is right though. > > Yes it's small, and there's a reason for it. So I'm giving a > conditional nack to the patch. > > > > This patch adds 'graph_filter_size' file in the tracefs to adjust the > > size. It can be changed only if the current tracer is not set. > > > > Signed-off-by: Namhyung Kim > > The condition is, we need to fix ftrace_graph_addr() first. > > for (i = 0; i < ftrace_graph_count; i++) { > > That gets called at every function being traced. See where I'm heading > with that? ;-) > > We need to create a hash table or binary search first and make that > function handle a large ftrace_graph_count before implementing your > patch. Remove the linear search, replace it with either a binary search > or a hash. But an O(n) algorithm at every function call is out of the > question. Fair enough. I'll try to add a hash table then. But I'm not sure how to synchronize hash table manipulations. It seems synchronize_sched() is not good enough for function graph tracer, right? So I limited changing filter size only when no tracer is used, but is it ok to have the limitation when adding or removing an entry to/from the table? If not, what can I do? Thanks, Namhyung