Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1676958ybv; Fri, 21 Feb 2020 01:30:23 -0800 (PST) X-Google-Smtp-Source: APXvYqwaQ8GaCsNI1c+OJ7b/Y+/i6W/+bokiAU8hzsYjxyzHbbjIaF8zDe6cg7W3d5MDKPdEEWh5 X-Received: by 2002:aca:fcc1:: with SMTP id a184mr1197367oii.36.1582277423064; Fri, 21 Feb 2020 01:30:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582277423; cv=none; d=google.com; s=arc-20160816; b=AK2RNi8i27moBBMFywTKFZUtfBuqXBr2NSyiIDobemOMds7oyp8uJBFNMd64LvrxqK b2kX9dA20d9wL4KItjXrgbpV32o8r7ZgLHdNcj4Kqms6pp/b9I6oYEzhsBOe39AKQNDG llDakVSR2f0wesfneqJVind27qx6jquDuL4SYTl5pe7+sGNOhqB2v9C/RKGKpptuvwPt sWzVn3oUwsENo6QRuCFgbyyheGhRdfnrb/45yiqKo4EaWzSfvK8b7ulXj1O317i4D/32 D2EZ3MiX7w+iWs4W5twpOL6DmszNKdSKv/jeCJraxIRaQ3/Ijch7iYV9Qm3xQjIB+m36 +WOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=TShdym3aikXo5YSTtobHYp8yUze7uiW4zE6z8XWtsDM=; b=U3BCW1qxz9Sxq4PK2wkTov52BEvSWNQD3U8BLfdZeA/CGZ5t/asWHovitvPMr62mjP C4anoylNiE3z9eF0hmCa68vSn3M4KyfFfyTXkRVE+bI3FBW4tbamqS2Zaiz3eW7Fc1N8 jrjYllpKTfzxSJn++qBCBQkWZEq15oEOa0lAYdubmoScsxE34T4A0TJqQKCNsd+M5kOG 4aolOf7/yUdq21hYp/cZF5fMM5Lp8FPZtslPvDaloTKBhEekRbydmECHuM8hALxiqDeB VlAgOPXMUTmzJ0pzyWTv/t2iEGmBM7jjhWk0MGf4XZ5QPeGOhys3KKerPod1afkA9nqe smyQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9si509839oie.148.2020.02.21.01.30.10; Fri, 21 Feb 2020 01:30:23 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727142AbgBUJaC (ORCPT + 99 others); Fri, 21 Feb 2020 04:30:02 -0500 Received: from foss.arm.com ([217.140.110.172]:34970 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726853AbgBUJaC (ORCPT ); Fri, 21 Feb 2020 04:30:02 -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 6ED4B31B; Fri, 21 Feb 2020 01:30:01 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 88FCD3F68F; Fri, 21 Feb 2020 01:29:59 -0800 (PST) Date: Fri, 21 Feb 2020 09:29:57 +0000 From: Qais Yousef To: chris hyser Cc: Parth Shah , vincent.guittot@linaro.org, patrick.bellasi@matbug.net, valentin.schneider@arm.com, dhaval.giani@oracle.com, dietmar.eggemann@arm.com, linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, pavel@ucw.cz, qperret@qperret.net, David.Laight@ACULAB.COM, pjt@google.com, tj@kernel.org Subject: Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints Message-ID: <20200221092956.jpsfps2dgmhiu5vg@e107158-lin.cambridge.arm.com> References: <8ed0f40c-eeb4-c487-5420-a8eb185b5cdd@linux.ibm.com> <971909ed-d4e0-6afa-d20b-365ede5a195e@linux.ibm.com> <8e984496-e89b-d96c-d84e-2be7f0958ea4@oracle.com> <1e216d18-7ec0-4a0d-e124-b730d6e03e6f@oracle.com> <7429e0ae-41ff-e9c4-dd65-3ef1919f5f50@linux.ibm.com> <20200220150343.dvweamfnk257pg7z@e107158-lin.cambridge.arm.com> <9bb1437b-3de0-b0ca-6319-6be903b0758d@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9bb1437b-3de0-b0ca-6319-6be903b0758d@oracle.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/20/20 11:34, chris hyser wrote: > > > Whether called a hint or not, it is a trade-off to reduce latency of select > > > tasks at the expense of the throughput of the other tasks in the the system. > > > > Does it actually affect the throughput of the other tasks? I thought this will > > allow the scheduler to reduce latencies, for instance, when selecting which cpu > > it should land on. I can't see how this could hurt other tasks. > > This is why it is hard to argue about pure abstractions. The primary idea > mentioned so far for how these latencies are reduced is by short cutting the > brute-force search for something idle. If you don't find an idle cpu because > you didn't spend the time to look, then you pre-empted a task, possibly with > a large nice warm cache footprint that was cranking away on throughput. It > is ultimately going to be the usual latency vs throughput trade off. If > latency reduction were "free" we wouldn't need a per task attribute. We > would just do the reduction for all tasks, everywhere, all the time. This could still happen without the latency nice bias. I'm not sure if this falls under DoS; maybe if you end up spawning a lot of task with high latency nice value, then you might end up cramming a lot of tasks on a small subset of CPUs. But then, shouldn't the logic that uses latency_nice try to handle this case anyway since it could be legit? Not sure if this can be used by someone to trigger timing based attacks on another process. I can't fully see the whole security implications, but regardless. I do agree it is prudent to not allow tasks to set their own latency_nice. Mainly because the meaning of this flag will be system dependent and I think Admins are the better ones to decide how to use this flag for the system they're running on. I don't think application writers should be able to tweak their tasks latency_nice value. Not if they can't get the right privilege at least. > > > > > Can you expand on the scenario you have in mind please? > > Hopefully, the above helps. It was my original plan to introduce this with a > data laden RFC on the topic, but I felt the need to respond to Parth > immediately. I'm not currently pushing any particular change. Thanks! -- Qais Yousef