Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp977028imm; Fri, 28 Sep 2018 09:47:29 -0700 (PDT) X-Google-Smtp-Source: ACcGV62l03YK4SSpxsvcVttu0JNdtR+OUoTTZlv1ijHAc3u+/UL2TZHJUEV5T5Ds2WYJC5zOtHBV X-Received: by 2002:a65:594b:: with SMTP id g11-v6mr15902666pgu.260.1538153249716; Fri, 28 Sep 2018 09:47:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538153249; cv=none; d=google.com; s=arc-20160816; b=td1PFfwUgg2LhUiUACYBxYPo6yhroyuBBWF8MsKvdyzYXnUcGpR9gMSOFhho0DQggP h0jIbKuk24s6glEeKkG1d05kDCbdd4qqFYSRJ6pWwI3zABMNz3n0gExkVR0pBED9QIAm rUuEVnitCrpdx3AKvRVYMSZx2re0RkpAph4eH50TzJae5Cw5qMOKcokbVDA/KlO8IBqp YLmajJuI1jUdR6kR5XZQo+AAtj7DVk9OTEjK/2eo3m1oXfuD3dub4B0SWLUBut74ffE8 EzsG702yIh5KyXrJfSNZ+pQXGfyYvQ9OSSdri8/nNaWyQhOzF3lxU9Rps/P/reFk5LSO 0SpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=bld+VnZHzmH5jITF+rN/Hr8nuyy+G6e7pbEOctDCdrc=; b=WeP9aFhWHoDbh19up8uL1IsMJVpacEf739zmS6RTOi3MHnyjxBjg+WzBhDMuFTZ0Qu qySqawpF8Wl48EfhLo+w94qRsF7eiMD/1fbAYPtYHcVFAYaJo94sjz7iprUDNZ9wJHB4 Q4w1k3s/a1rpRTBWC0Xi7Ydnwqa/mz51FFfl4ivHHglC09soLBbfpih9B99x4nfGsT/H YNd0qIz4bkc1nj/A6+huQQj+4i7DZ3LLvUB+8MNDQv2estwbOOUbSJ/PATV9Ey0APK95 xFVxeVRdMdGBpti30uS5SV6PVIla3bWP/9J+Uo4m0hFBCq/LCU46ST9UMa10del2ITFv NTPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vbdDqSLL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6-v6si4946521pgk.623.2018.09.28.09.47.13; Fri, 28 Sep 2018 09:47:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vbdDqSLL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729124AbeI1XKV (ORCPT + 99 others); Fri, 28 Sep 2018 19:10:21 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:40376 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726971AbeI1XKV (ORCPT ); Fri, 28 Sep 2018 19:10:21 -0400 Received: by mail-qt1-f194.google.com with SMTP id e9-v6so7314276qtp.7 for ; Fri, 28 Sep 2018 09:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bld+VnZHzmH5jITF+rN/Hr8nuyy+G6e7pbEOctDCdrc=; b=vbdDqSLLhqbUy9xvU77G91sy22SjMM/mvo0YCtJLKvwCerQ5NAMEoK4a1xZ1/Rc7/l ZWFdp5H78lRpUOAtJMBYs7d1of/cedtArPY0YYK4NH3lpCh1njhCXbZyokkP9jWd+Tkb 6uj7y4WI3/D/epMTN4ka3x0J5XOgmsgq67a0nSxc4r8Dnm68vdR+FKwa/0quLbseKiQb Tz2xqlCLiFW40QsXDtd7RCOt6KTUChoUmBVmLz/EZmxu1oFyeqobdF97gGtx2ItjjOk5 pbhonvHzVwNIYZ5GCmM+PAUZ/mEr7oe83rxBM9bbE56iYdGosDj7wkVD6sq0C9wWDWVC x1HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bld+VnZHzmH5jITF+rN/Hr8nuyy+G6e7pbEOctDCdrc=; b=duQgBSE8/B4IPF65sGvVVOyRGkxKxU6DjdC9GSF5xSzzNz81mjHq8W9vUpH7T+Gp+1 yRkOvE/2u1bdTQe4dI+AvBIcL6D1m4w2YvgD+T0VaYVGEZUjaGviBRbZSwWFd6CUZIjx S34Ms+ZtTcb2K831A+UI8t8Ydb37ga0+2AnTSV+6SlIrQHig0hkDE9ccMMhLx+aDLBGo 3GPbsE3Tu6bH6Ytb5R+JM1WQHqguCSf3xYvHWeil1HGbo+0bgVPxydnbKiIhNRga7TYp VI8RGBFLlRM+ibumElIb6MjZVp5Pv158ik731H9FkVPsWL8e3cfhLZi3VSvwZN7CiGTP an6g== X-Gm-Message-State: ABuFfoh3RBBbiZ6Dk7JF92EXWTi7ZbsVyc03bKnA+noyc2WbLbWaGR4u qfg4av7Xm/u74iYf89YMkUS5MTa24Ns6W0dCBUSRxA== X-Received: by 2002:a0c:d48d:: with SMTP id u13-v6mr12605367qvh.165.1538153144179; Fri, 28 Sep 2018 09:45:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2abb:0:0:0:0:0 with HTTP; Fri, 28 Sep 2018 09:45:43 -0700 (PDT) In-Reply-To: References: <20180817182728.76129-1-smuckle@google.com> <20180824093227.GN24124@hirez.programming.kicks-ass.net> <20180824094742.GJ24142@hirez.programming.kicks-ass.net> <20180827111458.GB24124@hirez.programming.kicks-ass.net> <2ed346fa-dbe8-4928-928b-a34338b2d8c9@arm.com> <62134bba-b6bd-ba16-a49b-e4887c326559@arm.com> From: Joel Fernandes Date: Fri, 28 Sep 2018 09:45:43 -0700 Message-ID: Subject: Re: [PATCH] sched/fair: vruntime should normalize when switching from fair To: Steve Muckle Cc: Wanpeng Li , Dietmar Eggemann , Peter Zijlstra , Miguel de Dios , Ingo Molnar , LKML , "Cc: Android Kernel" , Todd Kjos , Paul Turner , Quentin Perret , Patrick Bellasi , Chris Redpath , Morten Rasmussen , John Dias , Wanpeng Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 28, 2018 at 9:10 AM, 'Steve Muckle' via kernel-team wrote: > On 09/27/2018 05:43 PM, Wanpeng Li wrote: >>>> >>>> On your CPU4: >>>> scheduler_ipi() >>>> -> sched_ttwu_pending() >>>> -> ttwu_do_activate() => p->sched_remote_wakeup should be >>>> false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not >>>> -> ttwu_activate() >>>> -> activate_task() >>>> -> enqueue_task() >>>> -> enqueue_task_fair() >>>> -> enqueue_entity() >>>> bool renorm = !(flags & >>>> ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATE) >>>> so renorm is false in enqueue_entity(), why you mentioned that the >>>> cfs_rq->min_vruntime is still added to the se->vruntime in >>>> enqueue_task_fair()? >>> >>> >>> Maybe this is a misunderstanding on my side but didn't you asked me to >>> '... Could you point out when the fair rq's min_vruntime is added to the >>> task's vruntime in your *later* scenario? ...' >> >> >> Yeah, if the calltrace above and my analysis is correct, then the fair >> rq's min_vruntime will not be added to the task's vruntime in your >> *later* scenario, which means that your patch is not necessary. > > > In the scenario I observed, the task is not waking - it is running and being > deboosted from priority inheritance, transitioning from RT to CFS. > > Dietmar and I both were able to reproduce the issue with the testcase I > posted earlier in this thread. Can this issue still show up say if the wake up was not remote? Say the task was locally awakened. In that case do we still need to check the class in vruntime_normalized like John was doing? Just want to make sure we caught all scenarios. - Joel