Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2471000pxb; Mon, 18 Jan 2021 20:18:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwTs3KDH2cRxAnrd291VpTXjrHyzgpzJDvykDUdEbCUXRc5ZxVjKnfODZdeVXswGuNgrEo7 X-Received: by 2002:aa7:c78c:: with SMTP id n12mr1925641eds.363.1611029936422; Mon, 18 Jan 2021 20:18:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611029936; cv=none; d=google.com; s=arc-20160816; b=jRVhLmG0r08RFSzHH3KsWzzBuG7TaKyQvj+GBYhlcKNaAKwvS6WDe89pYDVAy9iBl8 X96eVUv0CMHHMRSFSKNhEs8b+9RUVN32Xv2uHQow2g0TDBahYhct2HOPRsa2ylZqXHkS Bayz77hE22YdMARppBecXQdJqMTIlFA67AlgZTF3HshIO5AtiuvhCqwx5P5JH33A8jcQ 3bpdbOp682rufxwy0gTwtt/FyHBGgAQGgcSBgMGBcUC5PPlJF3n/k1cJiWSIjQYasB/h /7Vyd/lJ3HwMKemPPdDTzH3gDxarwR/35py6WPhf5zueNCzWFW8S/PJks2A+d3F4wNck zIuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=qskwrs9PcUI54IS2EGGfpMU4PDXQfqH5PObQuPS3H0M=; b=cC6Axva4IqWCVFxg7SGzab2YtP/gvMtQ+7GhIll6p4jxNpey2ATKSYG+ug8g0vmGub 6gKbpWO4Wo2HXXjDHU6tnsXCsO1NPWXpT9ojY0KuEL4XXGu922moPNfFMX3KTSn19ftw RlVDKcKwryrn1lYug3gQqChdq5vtlMK5/8AclFctJMYkE/gV5gAIYrWqkxaFuxFzVrEY tBTQ6YmgbYym2oj36gfExJ4PWoOFrFx0Ktt7splVIMQXr856k07I/mrgACjzIaQ7/zCT KDz6u9h8Cdtgcd7C8gm/FxcdPgdkeG3RphP5VOJaZtWitCRElv1Rytlj2ClIuP66MOr5 QogA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QXO1FenE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hr20si1891727ejc.23.2021.01.18.20.18.33; Mon, 18 Jan 2021 20:18:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QXO1FenE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404421AbhARNTn (ORCPT + 99 others); Mon, 18 Jan 2021 08:19:43 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:48634 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404391AbhARNTQ (ORCPT ); Mon, 18 Jan 2021 08:19:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610975869; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qskwrs9PcUI54IS2EGGfpMU4PDXQfqH5PObQuPS3H0M=; b=QXO1FenEnvBRQmJdcubmHUBxjkiI/Wbpcd8LYYmFJW5Zy92PrYUdPFxAsD+PC5V9kQb+8R A6SaCxwRqnKdgHWRP/6bGd7KedppMiTOmCqm/Uf5inwVyT1L6BUWufxrwyTXNBiuC5XMKF Ch0ZhDKIuyuYXOv4KI5wgz/KTs+AeJQ= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-325-jupv7Ix9OraMMA5kYsJVuw-1; Mon, 18 Jan 2021 08:17:46 -0500 X-MC-Unique: jupv7Ix9OraMMA5kYsJVuw-1 Received: by mail-ed1-f72.google.com with SMTP id m16so7794411edd.21 for ; Mon, 18 Jan 2021 05:17:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qskwrs9PcUI54IS2EGGfpMU4PDXQfqH5PObQuPS3H0M=; b=MjNRhKbA0O7/iIwYPigp307ruIfR0i3iiU5DfjOroEVgbADIxW468zYxsZPywEinSI o8IloPgos2iqrgOsrZtvKYLWW7gQdCXNiR7Q4KjLGgWArVnkG7HLBLFyeLyoQUcJV0DU owTQypQvLvGk3c/7JnG+TgtueGbnMQQpSdQZR3xgdAftn4xvEZk/2HKaX4hMe9qkZJlk S8XCUxBOGo0XFlYi+RRyOObFsVYuCozbJN9PWEAlqggkbPQFDL3jQ/tx8rGqEwyoi31E RcafCaF82ibqRC+E8OcS1hB5jeVPpr7L88/5hVq7A7VV+X4AZQqai5Oxl7xrIT7lw2OC smQQ== X-Gm-Message-State: AOAM533mYSQjYhJBuz7YmQTiuCgPrrNN9Rl1918Bf50jra0qZG4qxtNa VNVBIpZ6JKLxtCGWd6NctwzsvuD0yS5Ejq/O5Dm1Lk/qV/AVpTGVbDALxsRF7XMff6pIgmkAynt ZSguBTQhCtD2Ow99b59qSqxR2 X-Received: by 2002:a17:906:76c9:: with SMTP id q9mr17834268ejn.484.1610975865559; Mon, 18 Jan 2021 05:17:45 -0800 (PST) X-Received: by 2002:a17:906:76c9:: with SMTP id q9mr17834250ejn.484.1610975865377; Mon, 18 Jan 2021 05:17:45 -0800 (PST) Received: from x1.bristot.me (host-79-46-192-171.retail.telecomitalia.it. [79.46.192.171]) by smtp.gmail.com with ESMTPSA id zn8sm9810299ejb.39.2021.01.18.05.17.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jan 2021 05:17:44 -0800 (PST) Subject: Re: [PATCH 6/6] sched/deadline: Fixes cpu/rd/dl_bw references for suspended tasks To: Dietmar Eggemann , linux-kernel@vger.kernel.org Cc: Marco Perronet , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Li Zefan , Tejun Heo , Johannes Weiner , Valentin Schneider , cgroups@vger.kernel.org References: <8c1cb0c850e2f3ab1d7a533aa4b33a30f9dbeda5.1610463999.git.bristot@redhat.com> <97875017-a6bb-98ea-83f9-82e95db58aca@arm.com> From: Daniel Bristot de Oliveira Message-ID: <40b1f087-2411-8fb3-4aad-20791e63d940@redhat.com> Date: Mon, 18 Jan 2021 14:17:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <97875017-a6bb-98ea-83f9-82e95db58aca@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/15/21 3:36 PM, Dietmar Eggemann wrote: > On 12/01/2021 16:53, Daniel Bristot de Oliveira wrote: > > [...] > >> ----- %< ----- >> #!/bin/bash >> # Enter on the cgroup directory >> cd /sys/fs/cgroup/ >> >> # Check it if is cgroup v2 and enable cpuset >> if [ -e cgroup.subtree_control ]; then >> # Enable cpuset controller on cgroup v2 >> echo +cpuset > cgroup.subtree_control >> fi >> >> echo LOG: create an exclusive cpuset and assigned the CPU 0 to it >> # Create cpuset groups >> rmdir dl-group &> /dev/null >> mkdir dl-group >> >> # Restrict the task to the CPU 0 >> echo 0 > dl-group/cpuset.mems >> echo 0 > dl-group/cpuset.cpus >> echo root > dl-group/cpuset.cpus.partition >> >> echo LOG: dispatching a regular task >> sleep 100 & >> CPUSET_PID="$!" >> >> # let it settle down >> sleep 1 >> >> # Assign the second task to the cgroup > > There is only one task 'CPUSET_PID' involved here? Ooops, yep, I will remove the "second" part. >> echo LOG: moving the second DL task to the cpuset >> echo "$CPUSET_PID" > dl-group/cgroup.procs 2> /dev/null >> >> CPUSET_ALLOWED=`cat /proc/$CPUSET_PID/status | grep Cpus_allowed_list | awk '{print $2}'` >> >> chrt -p -d --sched-period 1000000000 --sched-runtime 100000000 0 $CPUSET_PID >> ACCEPTED=$? >> >> if [ $ACCEPTED == 0 ]; then >> echo PASS: the task became DL >> else >> echo FAIL: the task was rejected as DL >> fi > > [...] > >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 5961a97541c2..3c2775e6869f 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -5905,15 +5905,15 @@ static int __sched_setscheduler(struct task_struct *p, >> #ifdef CONFIG_SMP >> if (dl_bandwidth_enabled() && dl_policy(policy) && >> !(attr->sched_flags & SCHED_FLAG_SUGOV)) { >> - cpumask_t *span = rq->rd->span; >> + struct root_domain *rd = dl_task_rd(p); >> >> /* >> * Don't allow tasks with an affinity mask smaller than >> * the entire root_domain to become SCHED_DEADLINE. We >> * will also fail if there's no bandwidth available. >> */ >> - if (!cpumask_subset(span, p->cpus_ptr) || >> - rq->rd->dl_bw.bw == 0) { >> + if (!cpumask_subset(rd->span, p->cpus_ptr) || >> + rd->dl_bw.bw == 0) { >> retval = -EPERM; >> goto unlock; >> } >> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c >> index c221e14d5b86..1f6264cb8867 100644 >> --- a/kernel/sched/deadline.c >> +++ b/kernel/sched/deadline.c >> @@ -2678,8 +2678,8 @@ int sched_dl_overflow(struct task_struct *p, int policy, >> u64 period = attr->sched_period ?: attr->sched_deadline; >> u64 runtime = attr->sched_runtime; >> u64 new_bw = dl_policy(policy) ? to_ratio(period, runtime) : 0; >> - int cpus, err = -1, cpu = task_cpu(p); >> - struct dl_bw *dl_b = dl_bw_of(cpu); >> + int cpus, err = -1, cpu = dl_task_cpu(p); >> + struct dl_bw *dl_b = dl_task_root_bw(p); >> unsigned long cap; >> >> if (attr->sched_flags & SCHED_FLAG_SUGOV) >> > > Wouldn't it be sufficient to just introduce dl_task_cpu() and use the > correct cpu to get rd->span or struct dl_bw in __sched_setscheduler() > -> sched_dl_overflow()? While I think that having the dl_task_rd() makes the code more intuitive, I have no problem on not adding it... > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 5961a97541c2..0573f676696a 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -5905,7 +5905,8 @@ static int __sched_setscheduler(struct task_struct *p, > #ifdef CONFIG_SMP > if (dl_bandwidth_enabled() && dl_policy(policy) && > !(attr->sched_flags & SCHED_FLAG_SUGOV)) { > - cpumask_t *span = rq->rd->span; > + int cpu = dl_task_cpu(p); > + cpumask_t *span = cpu_rq(cpu)->rd->span; > > /* > * Don't allow tasks with an affinity mask smaller than > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index c221e14d5b86..308ecaaf3d28 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -2678,7 +2678,7 @@ int sched_dl_overflow(struct task_struct *p, int policy, > u64 period = attr->sched_period ?: attr->sched_deadline; > u64 runtime = attr->sched_runtime; > u64 new_bw = dl_policy(policy) ? to_ratio(period, runtime) : 0; > - int cpus, err = -1, cpu = task_cpu(p); > + int cpus, err = -1, cpu = dl_task_cpu(p); > struct dl_bw *dl_b = dl_bw_of(cpu); > unsigned long cap; > This way works for me too. Thanks! -- Daniel