From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752169AbcFWMrH (ORCPT ); Thu, 23 Jun 2016 08:47:07 -0400 Received: from mx2.suse.de ([195.135.220.15]:54172 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751166AbcFWMrF (ORCPT ); Thu, 23 Jun 2016 08:47:05 -0400 Date: Thu, 23 Jun 2016 14:47:03 +0200 (CEST) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Torsten Duwe cc: Miroslav Benes , Josh Poimboeuf , matz@suse.de, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Disable non-ABI-compliant optimisations for live patching In-Reply-To: Message-ID: References: <20160622142441.GA31609@lst.de> <20160622151911.7dgacgsgbcjopopz@treble> <20160623100550.GB31609@lst.de> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 23 Jun 2016, Jiri Kosina wrote: > > I haven't looked at the fentry solution, but the code I'm involved in saves > > the registers so that ftrace, live patch and friends can work freely. But > > then it restores all regs and _then_ calls the replacement, so ftrace > > saving all regs is no gain at all. > > You're right, thanks for bringing this up. > > In principle we should be able to modify the trampoline so that it > performs its own register saving (in ftrace_regs_caller) and restoring > (*), completely shielding the new function from any optimization gcc might > have done on registers, shouldn't we? > > (*) we'll have to piggy-back on ftrace_epilogue on that, i.e. making the > return to the original code go through trampoline as well (the same > way graph tracer works) Okay, after looking more about how ftrace implements the return trampolines for graph caller, it'd be rather difficult to implement in a way that we neither interfere with ftrace graph tracer (the ftrace_ret_stack in task_struct) nor introduce a serious performance overhead or stack usage pressure. I am pretty sure the overhead we'd be adding would be much worse than just really simply turning the IPA-RA off in CONFIG_LIVEPATCH-enabled kernels is the easiest way to go. After talking to Jan Hubicka, I'd actually suggest turning off most/all the IPA optimizations; they are supposed to be of questionable benefit for kernel anyway, and they might be causing serious issues for us. I am planning to ask our performance team to measure the impact this'd have. Thanks, -- Jiri Kosina SUSE Labs