Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2124651imm; Thu, 11 Oct 2018 05:37:14 -0700 (PDT) X-Google-Smtp-Source: ACcGV62EP1+FAZYW1cFG+r8REbb8784PGzZR9v901JWECyNwUkUvdXZnUwVMrwOqJ6fyivY3Sy1Q X-Received: by 2002:a62:6143:: with SMTP id v64-v6mr1422669pfb.125.1539261434113; Thu, 11 Oct 2018 05:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539261434; cv=none; d=google.com; s=arc-20160816; b=RWkcnBpnddQsdy4ZKrs0KSQIKGMOJXQSDj3hFSjCQD+g1l1YM9bFAOt3Hky3QYKQl9 abfAuvr/5T/BqFi2W5wVIWwmlCVBi2z+oX1RLdvwTtmmR4HInUb/oCqbCJ3HUVgLIPPY G5FfbbtEp4TowHxN6bv4lrRTOEPXTuubpEBDuYUdKezHAfl9NWLs/JUhys4os96Z7Fav aKwhWXbhiQOUmARVtNDPVvG4k7o4ub2sdURYoPF4ZvkJVnz5RFIMvHEjz4MQQ9NwkWE1 5cwa5Lxi9Grsgr0pV5KMwVLFn8JjtBbZbiUMZuKBUmztDNdd2qSiwAP/MYwCJQF59btJ iOCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=C5BM3ARmHFFxcdDf3fM419QcwmtH/92iuXIQvAJHaXg=; b=tRbrteFI46tDBYuMfD98XMbVThxCi62JDbsEEcL93OiedUPiF1ySxcG0VHDrBejZxr Pyf5OAT8QGasAuSZeTTB+DAl30d/l09wc2wTzbuuivzaPS6OZRrnI8Ev/PXlaeOxKTO5 hrjBF3f6TrN9N6zDlgWuwDLIlApQ9FwZ1LCu2Vd3hQ1yTsWLVZnCECaCbBUwebiaVGvn 4ZDPrclIWqhuJZ3d+mkxwCTEFbhnnppJFoehmk60OzURHq46KQDctgWJyDvfNR2SC6CU V5stktlnOu/ZvL/Bpi6cUPmc6402tvEDoLqp5NGZeb1riNarwXMFywv6o6tfDuHLDWEF 1Pyg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j13-v6si26059216pfn.288.2018.10.11.05.36.59; Thu, 11 Oct 2018 05:37:14 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728323AbeJKUBz (ORCPT + 99 others); Thu, 11 Oct 2018 16:01:55 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:38039 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726964AbeJKUBy (ORCPT ); Thu, 11 Oct 2018 16:01:54 -0400 Received: by mail-wm1-f66.google.com with SMTP id 193-v6so9213925wme.3 for ; Thu, 11 Oct 2018 05:34:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=C5BM3ARmHFFxcdDf3fM419QcwmtH/92iuXIQvAJHaXg=; b=FRXmYD0ZAzmfapkDhvfSeIlYnVA3zRRq23/La8eTolW6hXJ5nPhPslUtLUCCxgtbvp mKH/9K06dlZHG1sOLNmOftko+a0t0gYjxOH3lD1/i63JMRlTVQSVo7yCwX/N79uptuuS fejhNrbB/KkAu99zupi1vGzfRX96Xho4p2W40KrANVPXzL36mVzawK/OC0YdJngVv4HY g6cH0AUDX7wd8+1oOICjNETFTaaJdp4xr+ffDxnFvvby2jd0O6WnrFghMqzR2xwqT5oJ +B6hREWg/yNZ1vbCE13Cc4Z4r+gLRjq77SHZ9V4rik+1yBwoJH1U9gpfuEkOb/J1O4L/ D2GQ== X-Gm-Message-State: ABuFfojwIDpkDLaL4ue6WRTG2uhu08XuXulRnjpR8xYsm+ha4lVQze5A q4Po6Tge1cWG4XgrcNtOFTH6RQ== X-Received: by 2002:a1c:a696:: with SMTP id p144-v6mr1587556wme.14.1539261292370; Thu, 11 Oct 2018 05:34:52 -0700 (PDT) Received: from localhost.localdomain (p200300EF2BD31613C1F2E846AEDA540D.dip0.t-ipconnect.de. [2003:ef:2bd3:1613:c1f2:e846:aeda:540d]) by smtp.gmail.com with ESMTPSA id o126-v6sm19293589wmo.3.2018.10.11.05.34.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Oct 2018 05:34:51 -0700 (PDT) Date: Thu, 11 Oct 2018 14:34:48 +0200 From: Juri Lelli To: luca abeni Cc: peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, alessio.balsini@gmail.com, bristot@redhat.com, will.deacon@arm.com, andrea.parri@amarulasolutions.com, dietmar.eggemann@arm.com, patrick.bellasi@arm.com, henrik@austad.us, linux-rt-users@vger.kernel.org Subject: Re: [RFD/RFC PATCH 5/8] sched: Add proxy execution Message-ID: <20181011123448.GS9130@localhost.localdomain> References: <20181009092434.26221-1-juri.lelli@redhat.com> <20181009092434.26221-6-juri.lelli@redhat.com> <20181010131048.54afd1b6@luca64> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181010131048.54afd1b6@luca64> 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 Hi Luca, On 10/10/18 13:10, luca abeni wrote: > Hi, > > On Tue, 9 Oct 2018 11:24:31 +0200 > Juri Lelli wrote: > [...] > > +migrate_task: > [...] > > + put_prev_task(rq, next); > > + if (rq->curr != rq->idle) { > > + rq->proxy = rq->idle; > > + set_tsk_need_resched(rq->idle); > > + /* > > + * XXX [juril] don't we still need to migrate @next > > to > > + * @owner's CPU? > > + */ > > + return rq->idle; > > + } > > If I understand well, this code ends up migrating the task only if the > CPU was previously idle? (scheduling the idle task if the CPU was not > previously idle) > > Out of curiosity (I admit this is my ignorance), why is this needed? > If I understand well, after scheduling the idle task the scheduler will > be invoked again (because of the set_tsk_need_resched(rq->idle)) but I > do not understand why it is not possible to migrate task "p" immediately > (I would just check "rq->curr != p", to avoid migrating the currently > scheduled task). As the comment suggests, I was also puzzled by this bit. I'd be inclined to agree with you, it seems that the only case in which we want to "temporarily" schedule the idle task is if the proxy was executing (so it just blocked on the mutex and being scheduled out). If it wasn't we should be able to let the current "curr" continue executing, in this case returning it as next will mean that schedule takes the else branch and there isn't an actual context switch. > > + rq->proxy = &fake_task; [...] We can maybe also rq->proxy = rq->curr and return rq->curr in such a case, instead of the below? > > + return NULL; /* Retry task selection on _this_ CPU. */ Peter, what are we missing? :-)