Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2966162pxb; Tue, 19 Jan 2021 10:09:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzc6pRjUPqEUPc4Es6zrSxcWueeAqCqumWcGowpZ2nvJQspmkSRwHWXqsiJdI38S9HZBVt X-Received: by 2002:a17:907:d01:: with SMTP id gn1mr3469424ejc.130.1611079792790; Tue, 19 Jan 2021 10:09:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611079792; cv=none; d=google.com; s=arc-20160816; b=ldXJVf2nwdmJoNclGEU8nu4Q3m8fumBRVE8NjzDIuS9XqGjwTME2TgH0wA+hznQVZX YNkHYJ0ezi4+QIxmsQEHvZX9bDsckWRP7F9qmVwqYykQOA5iUnoAM9x9wUgOZ0GSZWVu 5Fd3iLVl9MSrdia+NR5lF+E/PBuRTtlqf/XnwSwl8d+xqpM7cIKDt+bUuowfqJAHk1qs lufNLpTzXEG3COOkmjNHVSAK6FGVNJuMcz80n8pzb9EwNYPLwtj2G9NeuZsRQ6h+wYe1 TbkJ89MiXPcOcWVaJOOc1sfOxlPStW8A8mHWxwYclZq5aHxyFPX1q65O4bvrhCmOSHam AP5Q== 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; bh=2GWEh+0hypi3baS2mVFf6RiVS8rSu1CCohCVvkj4g0A=; b=fT9lXUCQ7l8/klG/huBSAXyJqggoY0rFj4k7f4eahiDfeG4HbhYlck+zKNKw1xD6kF wo1i0koP244r1YpjtXHqcVfMWEHk+dwo5Vz44klxvlBluUxnNp7ub1ubKF382QJOY5La /aAlt9nz5N3KZr8++uOakoJ9xR0SMuXY7/KTd9/jmgfVfbw96THxTyQg5RVzalSErRZK 19kNGjRR1pes25VGWbPsHw7nsnMcSczNYQA1DL0mefWA18qPyY2Ozt+IeHpR25oRNTQT uFPYlayV3RzVhHXJXtyK53BOvuXrPxY2tcAEbfKKwysYh1QT1tga8/S+pjwsWIekg5w6 +aAQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mb27si3101646ejb.165.2021.01.19.10.09.20; Tue, 19 Jan 2021 10:09:52 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404634AbhASSGk (ORCPT + 99 others); Tue, 19 Jan 2021 13:06:40 -0500 Received: from foss.arm.com ([217.140.110.172]:42292 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731672AbhASRng (ORCPT ); Tue, 19 Jan 2021 12:43:36 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 134BE139F; Tue, 19 Jan 2021 09:42:48 -0800 (PST) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 106403F66E; Tue, 19 Jan 2021 09:42:46 -0800 (PST) Date: Tue, 19 Jan 2021 17:42:44 +0000 From: Qais Yousef To: Quentin Perret Cc: "Peter Zijlstra (Intel)" , Dietmar Eggemann , Vincent Guittot , linux-kernel@vger.kernel.org, Valentin Schneider , Morten Rasmussen Subject: Re: [PATCH] sched/eas: Don't update misfit status if the task is pinned Message-ID: <20210119174244.3p2graxd5gonv4di@e107158-lin> References: <20210119120755.2425264-1-qais.yousef@arm.com> <20210119164027.drfpmrol3xhf4ckc@e107158-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/19/21 16:55, Quentin Perret wrote: > On Tuesday 19 Jan 2021 at 16:40:27 (+0000), Qais Yousef wrote: > > On 01/19/21 15:35, Quentin Perret wrote: > > > Do you mean failing the sched_setaffinity syscall if e.g. the task > > > has a min clamp that is higher than the capacity of the CPUs to which it > > > will be pinned? If so, I'm not sure if we really want that. > > > > No. In Android for instance, I'm worried a background task affined to little > > cores that has a utilization > capacity_of(little) will trigger the same > > problem. It'll be affined to more than just 1 cpu, but none of the little cpus > > will actually fit. > > > > Makes sense? > > Now yes. > > I agree this may be a real problem, but capacity_of() very much is a > per-CPU thing, because of RT pressure and such, and that is not a static > thing by any mean. So, even if the task doesn't fit on any CPU _now_ we > might still want to mark it misfit, just so it can be picked up by a > potential idle balance on another CPU later on. Maybe capacity_orig_of > would be preferable? Hmm IIUC you want to still tag it as misfit so it'll be balanced within the little cores in case there's another core with more spare capacity, right? This needs more thinking. Misfit doesn't seem the right mechanism to handle this. If there are multiple tasks crammed on the same CPU, then we should try to distribute yes. If it is the only task I can't see this being useful unless the pressure is very high. Which could be an indication of another problem in the system.. Thanks -- Qais Yousef