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;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 90362600ED
Date:   Tue, 26 Jun 2018 15:17:12 +0530
From:   Pavan Kondeti <pkondeti@codeaurora.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     linux-kernel@vger.kernel.org
Subject: Question about wakeup granularity calculation in
 wakeup_preempt_entity()
Message-ID: <20180626094712.GF9208@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Peter,

I have a question about wakeup granularity calculation while checking
if the waking fair task can preempt the current running fair task.

static unsigned long
wakeup_gran(struct sched_entity *curr, struct sched_entity *se)
{
	unsigned long gran = sysctl_sched_wakeup_granularity;

	/*
	 * Since its curr running now, convert the gran from real-time
	 * to virtual-time in his units.
	 *
	 * By using 'se' instead of 'curr' we penalize light tasks, so
	 * they get preempted easier. That is, if 'se' < 'curr' then
	 * the resulting gran will be larger, therefore penalizing the
	 * lighter, if otoh 'se' > 'curr' then the resulting gran will
	 * be smaller, again penalizing the lighter task.
	 *
	 * This is especially important for buddies when the leftmost
	 * task is higher priority than the buddy.
	 */
	return calc_delta_fair(gran, se);
}

The above comment says that the wakeup granularity will be larger when
'se' < 'curr'. But we completely ignore the weight of the curr and
scale the wakeup granularity solely based on the weight of the waking
task i.e se. 

For example, when curr is nice:0 and se is nice:0, the wakeup granularity
is unchanged. However when curr is nice:-15 and se is nice:-15, the
granularity becomes 3% of its original value and favour the waking task.

The git history around these functions revealed that there was once a
sched feature called ASYM_GRAN with which we can control the granularity
scaling wrt curr or se. However if we scale granularity wrt curr, then
preemption becomes difficult for a higher waking up task. 

Is there any reason why we don't want to take both curr and se into account?

scaled_granularity = granularity * (W(curr)/W(se))

I don't have any particular usecase that actually shows a regression. I
spotted this behavior in traces where a lower or default prio task that
is riding on the wakeup bonus is preempting a higher prio task which started
just running. Setting sched_wakeup_granularity to a value higher than the
wakeup bouns may prevent this, but that would make things difficult for
a normal prio tasks preempting a lower prio running task.

Thanks,
Pavan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.