Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2245284imm; Sat, 2 Jun 2018 22:21:37 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLY0bxplUwwrYaQEauCYYiEaA6X3WdScVhl7YIHPUGuxO7nzrSy5Kfl96qNpAKZcBPIkObH X-Received: by 2002:a17:902:268:: with SMTP id 95-v6mr17167497plc.386.1528003297591; Sat, 02 Jun 2018 22:21:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528003297; cv=none; d=google.com; s=arc-20160816; b=U8koU7s8nbMDzsBIczT12CFqA3TV0maEa3fSlMA0JB1mEpCLO9oV7UHG+5kNO00seO d+r9HB7+1xQ9YYJkW3AKR/ik/QUS4dV4moLMkDfABf2Li/c+SMpnUlII0L6fvQVFt9p1 p2tcTo3MzHA2dVqNX3VGPPhWt1sPaJG+qbGR4N8H8x4mJHeCbyTQq9xNwkPuqkt0bRq2 2E2JqcSWyzva63MoSEC53bmJMXPFZhgmjPt3uqS5g/ewwzkCy2JYk+csMZ0fhPEHv5kG 0G4Qq1/j8uggZpeAlFLmNozQAl2B+crLIU5aVtQ/gB+uLCBrYdpJ8LtVoVUbGuyC5+Nx c5Yg== 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 :arc-authentication-results; bh=cfWpk7xakoPpp0XCbhcL/9JSirxrPkqupilsQjGSGEs=; b=fRT134vPaHVgt6bFk1zudSHmt/AX3mQwcOJSwNlDZ73s1Kb4+uXU0DM4iFPwmyDGGM 9gH9wew9vpwtLUzqBw39qo7WwJDhzNQ72Px4/p2054gUSzoOcS0GvL07HU26HQrLfBNu M97XBEZCzoNgwfugH9rfNnqsQZc77Jfy/piI/9MmrfTO2q4xhsqRuL1P1l9jcW5pqKkx IV7xkiHaCOL2V4XjrWgMMmN8nfLUC7YaOgBYOCvfm1lohhRonDhpQGbrXQAV1DR3Shq0 9FDiywg2a3ObZKA4Nypi6u3wmr117W2OK01l6LrnW056j6DvvO0hU032EKbl7eFe+rrR FhYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AJGSj3Br; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i2-v6si1426585pgo.289.2018.06.02.22.21.08; Sat, 02 Jun 2018 22:21:37 -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=@gmail.com header.s=20161025 header.b=AJGSj3Br; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750846AbeFCFUg (ORCPT + 99 others); Sun, 3 Jun 2018 01:20:36 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:33077 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750786AbeFCFUe (ORCPT ); Sun, 3 Jun 2018 01:20:34 -0400 Received: by mail-lf0-f66.google.com with SMTP id y20-v6so20366301lfy.0 for ; Sat, 02 Jun 2018 22:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cfWpk7xakoPpp0XCbhcL/9JSirxrPkqupilsQjGSGEs=; b=AJGSj3BrdVf0I7HLATph+lTna7HTehYdcwkOWl1e48oPB0BadmPDNU0tuPB84jMnXY sOJy87jY/jo8kIlmTbHPhA32bnuENT9nPNtVUynZN9/QqXobgU8gbsukl9KfPiwUFZ9E uhjqrFuV9X0F5K0+Kx5PpCL+d0nGn4Ja/25++j/Ad9nKzYSpPL8rWRurfanHo1emXPzi WiODE3lsW8OOVvtANLSGrIQNajTyodWjA3VlGoC//XX67ylZfn/bDqtnFiQDgViRBBrd NQM5v77WC7NWBUBq3DqLcHvgcTB+HMQlMgFJ/h0UTMuBovn6yrAnEtAqWuXWUCcJC5Oi rW8g== 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=cfWpk7xakoPpp0XCbhcL/9JSirxrPkqupilsQjGSGEs=; b=cIf8+H22+1ydUmiOLjVbTFOQomwCihQ+C3cWuwPW8s1MX2BN532DXvdKYEOLheOzcP LXJeQXOUb1RThFUvu2sVO7p7eyDMLnTZByVPqY/qIiNhdwWeNMTFnIjJNJrX2DlUhLdk CtEblR/uu6FtrZ0VDNxk3KwKSX9ayvyzwxLELYFkJnNcLsp+QFxb2zE53G8BWNXM97SD 4liQgK8f6zsIHPbJ5x5EI+J5FBDqaI4IU00Fa9v4e63AUYjVRkcm2dZhwg1qqejbp0mW Mex9ujSYKLcVYFugeoOE+e/29+beCLJ25JTXMyBLz8VlsJnUWhEP8GhR99gsk17bkED3 cURw== X-Gm-Message-State: APt69E2SsIBhx9iofldvRShV2EtaNKy09yBdrRuG9MkscKUBhANy+zL2 EVzDnT24p9Gfmv3KLALYTVsRns6HRlc/wvbPZ4I= X-Received: by 2002:a2e:980f:: with SMTP id a15-v6mr6103577ljj.143.1528003232938; Sat, 02 Jun 2018 22:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:7315:0:0:0:0:0 with HTTP; Sat, 2 Jun 2018 22:20:32 -0700 (PDT) In-Reply-To: <20180601155235.GA66123@joelaf.mtv.corp.google.com> References: <1515392081-32320-2-git-send-email-byungchul.park@lge.com> <20180601061255.GA189147@joelaf.mtv.corp.google.com> <20180601061841.GA191514@joelaf.mtv.corp.google.com> <20180601155235.GA66123@joelaf.mtv.corp.google.com> From: Byungchul Park Date: Sun, 3 Jun 2018 14:20:32 +0900 Message-ID: Subject: Re: [RESEND, v3, 2/2] sched/deadline: Initialize cp->elements[].cpu to an invalid value To: Joel Fernandes Cc: Byungchul Park , Peter Zijlstra , Ingo Molnar , rostedt@goodmis.org, Thomas Gleixner , raistlin@linux.it, linux-kernel@vger.kernel.org, Juri Lelli , bristot@redhat.com, kernel-team@lge.com, kernel-team@android.com 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 Sat, Jun 2, 2018 at 12:52 AM, Joel Fernandes wrote: > On Fri, Jun 01, 2018 at 04:10:56PM +0900, Byungchul Park wrote: >> > On Thu, May 31, 2018 at 11:12:55PM -0700, Joel Fernandes wrote: >> > > On Mon, Jan 08, 2018 at 03:14:41PM +0900, byungchul park wrote: >> > > > Currently, migrating tasks to cpu0 unconditionally happens when the >> > > > heap is empty, since cp->elements[].cpu was initialized to 0(=cpu0). >> > > > We have to distinguish between the empty case and cpu0 to avoid the >> > > > unnecessary migrations. Therefore, it has to return an invalid value >> > > > e.i. -1 in that case. >> > > > >> > > > Signed-off-by: Byungchul Park >> > > > Acked-by: Steven Rostedt (VMware) >> > > > Acked-by: Daniel Bristot de Oliveira >> > > > --- >> > > > kernel/sched/cpudeadline.c | 10 +++++++++- >> > > > 1 file changed, 9 insertions(+), 1 deletion(-) >> > > > >> > > > diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c >> > > > index 9f02035..bcf903f 100644 >> > > > --- a/kernel/sched/cpudeadline.c >> > > > +++ b/kernel/sched/cpudeadline.c >> > > > @@ -138,6 +138,12 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p, >> > > > int best_cpu = cpudl_maximum_cpu(cp); >> > > > WARN_ON(best_cpu != -1 && !cpu_present(best_cpu)); >> > > > + /* >> > > > + * The heap tree is empty for now, just return. >> > > > + */ >> > > > + if (best_cpu == -1) >> > > > + return 0; >> > > > + >> > > > if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) && >> > > > dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) { >> > > > if (later_mask) >> > > > @@ -265,8 +271,10 @@ int cpudl_init(struct cpudl *cp) >> > > > return -ENOMEM; >> > > > } >> > > > - for_each_possible_cpu(i) >> > > > + for_each_possible_cpu(i) { >> > > > + cp->elements[i].cpu = -1; >> > > > cp->elements[i].idx = IDX_INVALID; >> > > >> > > Shouldn't you also set cp->elements[cpu].cpu to -1 in cpudl_clear (when you >> > > set cp->elements[cpu].cpu to IDX_INVALID there)? >> > >> > I messed up my words, I meant : "when setting cp->elements[cpu].idx to >> > IDX_INVALID there". Which means I need to call it a day :-) >> >> Ah.. I agree with you. It might be a problem when removing the last >> element.. Then I think the following change should also be applied >> additionally. Right? > > Yes. > >> --- >> diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c >> index 8d9562d..44d4c88 100644 >> --- a/kernel/sched/cpudeadline.c >> +++ b/kernel/sched/cpudeadline.c >> @@ -172,12 +172,14 @@ void cpudl_clear(struct cpudl *cp, int cpu) >> } else { >> new_cpu = cp->elements[cp->size - 1].cpu; >> cp->elements[old_idx].dl = cp->elements[cp->size - 1].dl; >> - cp->elements[old_idx].cpu = new_cpu; >> + cp->elements[old_idx].cpu = (new_cpu == cpu) ? -1 : new_cpu; >> cp->size--; >> - cp->elements[new_cpu].idx = old_idx; >> cp->elements[cpu].idx = IDX_INVALID; >> - cpudl_heapify(cp, old_idx); >> >> + if (new_cpu != cpu) { >> + cp->elements[new_cpu].idx = old_idx; >> + cpudl_heapify(cp, old_idx); >> + } >> cpumask_set_cpu(cpu, cp->free_cpus); > > This looks a bit confusing. How about the following? (untested) Hello, Whatever. Your code also looks good to me. I just wanna follow the maintainers' decision. ;) > thanks, > > - Joel > > ---8<----------------------- > > diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c > index 50316455ea66..741a97e58c05 100644 > --- a/kernel/sched/cpudeadline.c > +++ b/kernel/sched/cpudeadline.c > @@ -129,6 +129,10 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p, > } else { > int best_cpu = cpudl_maximum(cp); > > + /* The max-heap is empty, just return. */ > + if (best_cpu == -1) > + return 0; > + > WARN_ON(best_cpu != -1 && !cpu_present(best_cpu)); > > if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) && > @@ -167,6 +171,12 @@ void cpudl_clear(struct cpudl *cp, int cpu) > * This could happen if a rq_offline_dl is > * called for a CPU without -dl tasks running. > */ > + } else if (cp->size == 1) { > + /* Only one element in max-heap, clear it */ > + cp->elements[0].cpu = -1; > + cp->elements[cpu].idx = IDX_INVALID; > + cp->size--; > + cpumask_set_cpu(cpu, cp->free_cpus); > } else { > new_cpu = cp->elements[cp->size - 1].cpu; > cp->elements[old_idx].dl = cp->elements[cp->size - 1].dl; > @@ -262,6 +272,9 @@ int cpudl_init(struct cpudl *cp) > for_each_possible_cpu(i) > cp->elements[i].idx = IDX_INVALID; > > + /* Mark heap as initially empty */ > + cp->elements[0].cpu = -1; > + > return 0; > } > -- Thanks, Byungchul