Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934729AbcDMKfT (ORCPT ); Wed, 13 Apr 2016 06:35:19 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:33655 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932418AbcDMKfR (ORCPT ); Wed, 13 Apr 2016 06:35:17 -0400 MIME-Version: 1.0 In-Reply-To: <20160413100839.GH5609@e106622-lin> References: <1460438960-32060-1-git-send-email-bill.huey@gmail.com> <20160413085708.GB11651@pablo> <20160413100839.GH5609@e106622-lin> Date: Wed, 13 Apr 2016 03:35:15 -0700 Message-ID: Subject: Re: [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC From: "Bill Huey (hui)" To: Juri Lelli Cc: Peter Zijlstra , Steven Rostedt , Linux Kernel Mailing List , Dario Faggioli , Alessandro Zummo , Thomas Gleixner , Amir Frenkel , luca abeni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3240 Lines: 72 Hi, On Wed, Apr 13, 2016 at 3:08 AM, Juri Lelli wrote: > I'm not sure what you mean by "localized", but I believe DEADLINE should > be used more widely to service the same kind of applications you are > referring to. It's still a quite new addition to the scheduler, so it is > understandable that we still have some legacy to fight. But we can get > better in the future. Yeah, I've known about it for a while but it's just so hard for me to imagine using that for the kinds of cases that I'm thinking about for mixed tasks. I just don't have an example in my head how that would work since I don't have a view of how something like EDF would solve some of the basic cases. That's mostly my ignorance. The original inspiration for this was problems with how FIFO tasks would run for long periods of time will stall with touch event handlers. The solution in multi-media circles seemed to be that (1) using larger buffers to avoid dropouts were the solution only to cause starvation and other problems with other important threads. There has to be some kind of global view of how a system should run. It's hard for me (self ignorance) to see how something like deadline would run for continuously running tasks like that under those scenarios and have that define some kind of global running policy in the system. That's why I created this for a brain dead view of how to hack this stuff, with some kind of crude execution pattern, to somehow get some level of acceptable interactivity yet meet basic hard requirements with audio etc. Might be a scenario where one would use sched_switch data to help with deciding that. We ran into a lot of problems with the Qualcomm MSM architecture and their power management code. Some of the hacks were pretty brutal and wasted processor time polling the second core aggressively. I wanted to solve all of these problems more completely and outside of the current work being done for better or worse. >> 2) The need for a scheduler to be driven by an external interrupt from a >> number sources directly. > > If you use DEADLINE to service the activity an interrupt source might > trigger, I think you can already do this. I'll have to think about this. Would might having a simple example here. >> 3) The need for a global view of the system so that power management >> decisions can be made sensibly made in multicore systems. It's not a >> scheduler alone but ideal would have more influence over power management >> decision on battery powered devices, etc... > > That's true. But it is also already something we currently are working on. > I don't know if you are following the schedfreq/schedutil threads [1], for > example, but there we are discussing how to integrate scheduler and > cpufreq more closely. And you might also be interested in the EAS effort > [2]. Not yet but I'll look for them. > OK. Feel free to ask if you also decide to experiment with DEADLINE and > find any problem with it. > [1] https://lkml.org/lkml/2016/3/17/420 > https://lkml.org/lkml/2016/2/22/1037 > [2] https://lkml.org/lkml/2015/7/7/754 Thanks, reading them now but they're quite complicated and the threads are quite long. It'll take time to digest it all Thanks bill