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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 99BEBC43387 for ; Tue, 8 Jan 2019 17:27:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5B4FE20883 for ; Tue, 8 Jan 2019 17:27:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728929AbfAHR1X (ORCPT ); Tue, 8 Jan 2019 12:27:23 -0500 Received: from mga12.intel.com ([192.55.52.136]:10558 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728278AbfAHR1W (ORCPT ); Tue, 8 Jan 2019 12:27:22 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 09:27:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,455,1539673200"; d="scan'208";a="124321665" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by FMSMGA003.fm.intel.com with ESMTP; 08 Jan 2019 09:27:21 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 94DE1301BEF; Tue, 8 Jan 2019 09:27:21 -0800 (PST) Date: Tue, 8 Jan 2019 09:27:21 -0800 From: Andi Kleen To: Peter Zijlstra Cc: Adrian Hunter , 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 Subject: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion Message-ID: <20190108172721.GN6118@tassilo.jf.intel.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> <306d38fb-7ce6-a3ec-a351-6c117559ebaa@intel.com> <20190108101058.GB6808@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190108101058.GB6808@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 08, 2019 at 11:10:58AM +0100, Peter Zijlstra wrote: > On Tue, Jan 08, 2019 at 12:01:11PM +0200, Adrian Hunter wrote: > > The problem is that the jitted code gets freed from memory, which is why I > > suggested the ability to pin it for a while. > > Then what do you tell the guy that keeps PT running for a day and runs > out of memory because he likes to JIT a lot? It only would need to be saved until the next kcore dump, so they would need to do regular kcore dumps, after each of which the JIT code could be freed. In a sense it would be like RCU for code. You would somehow need to tell the kernel when that happens though so it can schedule the frees. It doesn't work when the code is modified in place, like the patch in the $SUBJECT. -Andi