Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756614AbcDGXPT (ORCPT ); Thu, 7 Apr 2016 19:15:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35382 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754166AbcDGXPR (ORCPT ); Thu, 7 Apr 2016 19:15:17 -0400 Date: Thu, 7 Apr 2016 19:15:13 -0400 From: Jessica Yu To: Jiri Kosina Cc: 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: <20160407231512.GA27994@packer-debian-8-amd64.digitalocean.com> References: <24db5a6ae5b63dfcd2096a12d18e1399a351348e.1458933243.git.jpoimboe@redhat.com> <20160407211525.GB25804@packer-debian-8-amd64.digitalocean.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1864 Lines: 42 +++ Jiri Kosina [07/04/16 23:37 +0200]: >On Thu, 7 Apr 2016, Jessica Yu wrote: > >> Been sort of rattling my head over the scheduler code :-) Just following >> the calls in and out of __schedule() it doesn't look like there is a >> current flag/mechanism to tell whether or not a task has been >> preempted.. > >Performing the complete stack unwind just to determine whether task has >been preempted non-volutarily is a slight overkill indeed :/ > >> Is there any reason why you didn't just create a new task flag, >> something like TIF_PREEMPTED_IRQ, which would be set once >> preempt_schedule_irq() is entered and unset after __schedule() returns >> (for that task)? This would roughly correspond to setting the task flag >> when the frame for preempt_schedule_irq() is pushed and unsetting it >> just before the frame preempt_schedule_irq() is popped for that task. >> This seems simpler than walking through all the frames just to see if >> in_preempt_schedule_irq() had been called. Would that work? > >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? >That has advantages of both aproaches combined, i.e. it's relatively >low-cost in terms of performance penalty, and it's reliable (in a sense >that you don't have false positives). > >The small disadvantage is that you can (very rarely, depending on the >chosen magic) have false negatives. That probably doesn't hurt too much, >given the high inprobability and non-lethal consequences. > >How does that sound? > >-- >Jiri Kosina >SUSE Labs >