Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1400185pxj; Fri, 21 May 2021 13:19:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJya/iqOZB08EuKWRSdwGXhrUSKAI8qdWbFNlWEl2UfvYewkLx0k8SRaodYQ63ykEs5iBuGX X-Received: by 2002:aa7:cfcd:: with SMTP id r13mr13216394edy.177.1621628362349; Fri, 21 May 2021 13:19:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621628362; cv=none; d=google.com; s=arc-20160816; b=cD/QYORg48Pc5+EhHlgqOIWXEdNxTfyjw6/o1NvOEjKCAABV7XJBeSJCF+tk6L40Db 7Er/z5D+LYO23Lvlbx/dKanrcvyHmr3YSM97Fr+rjRrutu6b2VZXizGYLv859gt96nYj 8+Veiyw6R0voMI2GBkBxvD0J+cFdq5ji2UMi/LSgoAUAz//J31LYgsC9Tl3VVCm5DRmC AHVLXHO9zCNd2dBkKPUrH9i1rFmrJhEJ9sGNGJ+8qPuPSbbA1uKdUHIK2GlPeXmRYJVK OdJ9EV6lAMRrhe2blUKl3FnG9/SB06c2p4594uNVdFUr/s4GmEuX/DfcpFpsVq8IxSb2 M+PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0FWGnS1xTBJJ2Fo3anpEGnC99ELWCmAqg/0rfir/TOM=; b=s8bAw1SuJfQH8B+GJ91GWOg0bn/BHHCdqW1BIiG59mbcHQsVNhtBEz8mVN4szU500M XqdVigk0F7pHlgBeVtJWh2uzw/W8noNVpQ9EZ/Kj0tXdgXVdYiDvLJxqj153LfmmwKQq A7yHV2l5GN8E6nihNUb+KzmDFSrWMqrf5PsXDCWlXZUvGY4gM95ct8wZJ+krs/9XJy5X DerVhKAp4rhbHtvn90vgVEU8arqQtLC7XPdBRjyYzXX1dcuSaZgjWq2WF277gSRwOaFq WfAkr89IvzJe49OYI4AbnUFS11HHeT7dhCtQR+mmbS3P8n7qX/1fhRoPIq8IJsd+87xM SwdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=S0WjffjO; 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 w9si6737105edx.381.2021.05.21.13.18.59; Fri, 21 May 2021 13:19:22 -0700 (PDT) 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=S0WjffjO; 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 S235629AbhEUOFx (ORCPT + 99 others); Fri, 21 May 2021 10:05:53 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:32627 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232587AbhEUOFw (ORCPT ); Fri, 21 May 2021 10:05:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621605865; 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: in-reply-to:in-reply-to:references:references; bh=0FWGnS1xTBJJ2Fo3anpEGnC99ELWCmAqg/0rfir/TOM=; b=S0WjffjOEhgRFANVKlMKrnN+y0GZ4FN4QZZeY92/YjzgqVKFf/b1L2OCHm0d93cJPolVZ+ XwcoKuwhPw7IgYH2dRoSxL/X4RRL///iFkbiM6+7NxBHpRxsYnMb1nRjDYG88EzE1i8qPj z4KFsmzxG9iFXv3dyrw5S2HECSHJB2k= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-449-fEnEI5kjNqaz701bFFLNnw-1; Fri, 21 May 2021 10:04:23 -0400 X-MC-Unique: fEnEI5kjNqaz701bFFLNnw-1 Received: by mail-ed1-f71.google.com with SMTP id da10-20020a056402176ab029038f0fea1f51so3192388edb.13 for ; Fri, 21 May 2021 07:04:23 -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; bh=0FWGnS1xTBJJ2Fo3anpEGnC99ELWCmAqg/0rfir/TOM=; b=F4Lt1onQadAdqK3mkPkw8SByQF2D5jWlyNSxH70jYdMIj1Li7MQnQ8lHUQXFVtW+ua CBYCvoHyRk+XUuSc0DQtE7i6DFzXANJ/lXRJaL5mH8c5pGWBLBjEdzIazQ8ol5Gm40zo AwLw3o3oef1psbV8ea6ca+GuhQmrDA9mSpjoyWd/DKuilucB4NRv1l1WcIs352UvVcpn XB51jDrA7zgXfKZ6E7+E0Ptnq8PyFEXzSvnNdWifGKaJZyEa/dWDt9qkjBFxQTfglKSj 65YUxRe96EIpdmM3aZD13ZRMCH6Pzi/zIKVSuh+dXfSO8RmQwJ4ys+/AL1dRf6ix61Hr PS9A== X-Gm-Message-State: AOAM532RNbkAFiukm0BymOLHrsUk8gi9BnxPSumuxeUUTX0h0V7wrPGk wN9SxmkpKRZJm+nbzoEd0HRMbt84ddfe+BOS73iyZWo2Gc1gerCwM7SjBasaui4iZ2f89S3qH/z ItDDfkLYYuMwqvvVS0lEewog+ X-Received: by 2002:a17:906:7c4b:: with SMTP id g11mr10460873ejp.461.1621605862067; Fri, 21 May 2021 07:04:22 -0700 (PDT) X-Received: by 2002:a17:906:7c4b:: with SMTP id g11mr10460834ejp.461.1621605861789; Fri, 21 May 2021 07:04:21 -0700 (PDT) Received: from localhost.localdomain ([151.29.18.58]) by smtp.gmail.com with ESMTPSA id qo19sm3569598ejb.7.2021.05.21.07.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 May 2021 07:04:21 -0700 (PDT) Date: Fri, 21 May 2021 16:04:18 +0200 From: Juri Lelli To: Quentin Perret Cc: Dietmar Eggemann , Will Deacon , Daniel Bristot de Oliveira , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Tejun Heo , Johannes Weiner , Ingo Molnar , Vincent Guittot , "Rafael J. Wysocki" , kernel-team@android.com Subject: Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Message-ID: References: <20210520101640.GA10065@willie-the-truck> <20210520180138.GA10523@willie-the-truck> <20210521103724.GA11680@willie-the-truck> <3620bad5-2a27-0f9e-f1f0-70036997d33c@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/05/21 13:02, Quentin Perret wrote: ... > So I think Will has a point since, IIRC, the root domains get rebuilt > during hotplug. So you can imagine a case with a single root domain, but > CPUs 4-7 are offline. In this case, sched_setattr() will happily promote > a task to DL as long as its affinity mask is a superset of the rd span, > but things may get ugly when CPUs are plugged back in later on. > > This looks like an existing bug though. I just tried the following on a > system with 4 CPUs: > > // Create a task affined to CPU [0-2] > > while true; do echo "Hi" > /dev/null; done & > [1] 560 > > mypid=$! > > taskset -p 7 $mypid > pid 560's current affinity mask: f > pid 560's new affinity mask: 7 > > // Try to move it DL, this should fail because of the affinity > > chrt -d -T 5000000 -P 16666666 -p 0 $mypid > chrt: failed to set pid 560's policy: Operation not permitted > > // Offline CPU 3, so the rd now covers CPUs 0-2 only > > echo 0 > /sys/devices/system/cpu/cpu3/online > [ 400.843830] CPU3: shutdown > [ 400.844100] psci: CPU3 killed (polled 0 ms) > > // Try to admit the task again, which now succeeds > > chrt -d -T 5000000 -P 16666666 -p 0 $mypid > > // Plug CPU3 back online > > echo 1 > /sys/devices/system/cpu/cpu3/online > [ 408.819337] Detected PIPT I-cache on CPU3 > [ 408.819642] GICv3: CPU3: found redistributor 3 region 0:0x0000000008100000 > [ 408.820165] CPU3: Booted secondary processor 0x0000000003 [0x410fd083] > > I don't see any easy way to fix this w/o iterating over all deadline > tasks in the rd when hotplugging a CPU back on, and blocking the hotplug > operation if it'll cause affinity issues. Urgh. > Yeah this looks like a plain existing bug, joy. :) We fixed a few around AC lately, but I guess work wasn't complete. Thanks, Juri