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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 03E8EC4360C for ; Fri, 4 Oct 2019 13:40:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D78EF222C2 for ; Fri, 4 Oct 2019 13:40:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388673AbfJDNkS (ORCPT ); Fri, 4 Oct 2019 09:40:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:46838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388272AbfJDNkR (ORCPT ); Fri, 4 Oct 2019 09:40:17 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5E2AE20700; Fri, 4 Oct 2019 13:40:16 +0000 (UTC) Date: Fri, 4 Oct 2019 09:40:14 -0400 From: Steven Rostedt To: Daniel Bristot de Oliveira Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, x86@kernel.org, Nadav Amit , Andy Lutomirski , Dave Hansen , Song Liu , Masami Hiramatsu Subject: Re: [PATCH 3/3] x86/ftrace: Use text_poke() Message-ID: <20191004094014.72a990ee@gandalf.local.home> In-Reply-To: <7b4196a4-b6e1-7e55-c3e1-a02d97c262c7@redhat.com> References: <20190827180622.159326993@infradead.org> <20190827181147.166658077@infradead.org> <20191002182106.GC4643@worktop.programming.kicks-ass.net> <20191003181045.7fb1a5b3@gandalf.local.home> <7b4196a4-b6e1-7e55-c3e1-a02d97c262c7@redhat.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Oct 2019 10:10:47 +0200 Daniel Bristot de Oliveira wrote: > [ In addition ] > > Currently, ftrace_rec entries are ordered inside the group of functions, but > "groups of function" are not ordered. So, the current int3 handler does a (*): > > for_each_group_of_functions: > check if the ip is in the range ----> n by the number of groups. > do a bsearch. ----> log(n) by the numbers of entry > in the group. > > If, instead, it uses an ordered vector, the complexity would be log(n) by the > total number of entries, which is better. So, how bad is the idea of: BTW, I'm currently rewriting the grouping of the vectors, in order to shrink the size of each dyn_ftrace_rec (as we discussed at Kernel Recipes). I can make the groups all sorted in doing so, thus we can load the sorted if that's needed, without doing anything special. > > in the enabling ftrace code path, it: > discover the number of entries > alloc a buffer > discover the order of the groups > for each group in the correct order > queue the entry in the buffer > apply the changes using the text_poke... > > In this way we would optimize the two hot-paths: > int3 will be log(n) > IPIs bounded to 3. > > I am not saying we need to do it now, as Steve said, not sure if this is a big > problem, but... those that don't like kernel interference may complain. But if > we leave the per-use-case vector in the text_poke_batch interface, things will > be easier to fix. > > NOTE: the other IPIs are generated by hooking the tracepoints and switching the > code to RO/RW... Yeah, I did a trace of who is doing the on_each_cpu() call, and saw it coming from the RO/RW changes, which this patch series removes. -- Steve > > * as far as I understood ftrace_location_range(). > > -- Daniel > > > -- Steve > >