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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 CFCE6C43387 for ; Tue, 8 Jan 2019 10:02:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2A65218AF for ; Tue, 8 Jan 2019 10:02:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728641AbfAHKCx (ORCPT ); Tue, 8 Jan 2019 05:02:53 -0500 Received: from mga02.intel.com ([134.134.136.20]:26948 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727001AbfAHKCw (ORCPT ); Tue, 8 Jan 2019 05:02:52 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 02:02:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,453,1539673200"; d="scan'208";a="116389408" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.56]) ([10.237.72.56]) by orsmga003.jf.intel.com with ESMTP; 08 Jan 2019 02:02:46 -0800 Subject: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion To: Peter Zijlstra Cc: Andi Kleen , Nadav Amit , Ingo Molnar , Andy Lutomirski , Josh Poimboeuf , Edward Cree , "H . Peter Anvin" , Thomas Gleixner , LKML , Nadav Amit , X86 ML , Paolo Abeni , Borislav Petkov , David Woodhouse , Alexander Shishkin , songliubraving@fb.com References: <20181231072112.21051-1-namit@vmware.com> <87zhshe66w.fsf@linux.intel.com> <20190107163227.GH14122@hirez.programming.kicks-ass.net> <20190108092559.GA6808@hirez.programming.kicks-ass.net> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <306d38fb-7ce6-a3ec-a351-6c117559ebaa@intel.com> Date: Tue, 8 Jan 2019 12:01:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190108092559.GA6808@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/01/19 11:25 AM, Peter Zijlstra wrote: > On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote: >> On 7/01/19 6:32 PM, Peter Zijlstra wrote: >>> On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote: >>>> Nadav Amit writes: >>>>> >>>>> - Do we use periodic learning or not? Josh suggested to reconfigure the >>>>> branches whenever a new target is found. However, I do not know at >>>>> this time how to do learning efficiently, without making learning much >>>>> more expensive. >>>> >>>> FWIW frequent patching will likely completely break perf Processor Trace >>>> decoding, which needs a somewhat stable kernel text image to decode the >>>> traces generated by the CPU. Right now it relies on kcore dumped after >>>> the trace usually being stable because jumplabel changes happen only >>>> infrequently. But if you start patching frequently this assumption will >>>> break. >>>> >>>> You would either need a way to turn this off, or provide >>>> updates for every change to the trace, so that the decoder can >>>> keep track. >>> >>> I'm thining it would be entirely possible to create and feed text_poke >>> events into the regular (!aux) buffer which can be timestamp correlated >>> to the PT data. >> >> To rebuild kernel text from such events would require a starting point. >> What is the starting point? The problem with kcore is that people can >> deconfig it without realising it is needed to enable the tracing of kernel >> self-modifying code. It would be nice if it was all tied together, so that >> if someone selects the ability to trace kernel self-modifying code, then all >> the bits needed are also selected. Perhaps we should expose another ELF >> image that contains only kernel executable code, and take the opportunity to >> put the symbols in it also. > > Meh; you always need a magic combo of CONFIG symbols to make stuff work. > We don't even have a CONFIG symbol for PT, so if you really care you > should probably start there. > > If you want symbols; what stops us from exposing kallsyms in kcore as > is? > >> Also what about BPF jitted code? Will it always fit in an event? I was >> thinking of trying to add a way to prevent temporarily the unload of modules >> or jitted code, which would be a good-enough solution for now. > > We're working on BPF and kallsym events, those should, esp. when > combined with kcore, allow you to extract the actual instructions. The problem is that the jitted code gets freed from memory, which is why I suggested the ability to pin it for a while.