Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757905AbcDHIDL (ORCPT ); Fri, 8 Apr 2016 04:03:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:42858 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753462AbcDHIDG (ORCPT ); Fri, 8 Apr 2016 04:03:06 -0400 Date: Fri, 8 Apr 2016 10:03:04 +0200 From: Petr Mladek To: Jiri Kosina Cc: Jessica Yu , Josh Poimboeuf , Miroslav Benes , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Vojtech Pavlik Subject: Re: sched: horrible way to detect whether a task has been preempted Message-ID: <20160408080304.GE5218@pathway.suse.cz> References: <24db5a6ae5b63dfcd2096a12d18e1399a351348e.1458933243.git.jpoimboe@redhat.com> <20160407211525.GB25804@packer-debian-8-amd64.digitalocean.com> <20160407231512.GA27994@packer-debian-8-amd64.digitalocean.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1143 Lines: 27 On Fri 2016-04-08 09:05:28, Jiri Kosina wrote: > On Thu, 7 Apr 2016, Jessica Yu wrote: > > > > Alternatively, without eating up a TIF_ space, it'd be possible to push a > > > magic contents on top of the stack in preempt_schedule_irq() (and pop it > > > once we are returning from there), and if such magic value is detected, we > > > just don't bother and claim unreliability. > > > > Ah, but wouldn't we still have to walk through the frames (i.e. enter > > the loop in patch 7/14) to look for the magic value in this approach? > > The idea was that it'd be located at a place to which saved stack pointer > of the sleeping task is pointing to (or at a fixed offset from it). It is an interesting idea but it looks even more hacky than checking the frame pointers and return values. Checking the stack might be an overkill but we already do this for all the other patched functions. The big advantage about checking the stack is that it does not add any overhead to the scheduler code, does not eat any TIF flag or memory. The overhead is only when we are migrating a task and it is charged to a separate process. Best Regards, Petr