Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030764AbcDMKHE (ORCPT ); Wed, 13 Apr 2016 06:07:04 -0400 Received: from foss.arm.com ([217.140.101.70]:33118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965432AbcDMKHC (ORCPT ); Wed, 13 Apr 2016 06:07:02 -0400 Date: Wed, 13 Apr 2016 11:08:39 +0100 From: Juri Lelli To: "Bill Huey (hui)" Cc: Peter Zijlstra , Steven Rostedt , Linux Kernel Mailing List , Dario Faggioli , Alessandro Zummo , Thomas Gleixner , KY Srinivasan , Amir Frenkel , Bdale Garbee , luca abeni Subject: Re: [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC Message-ID: <20160413100839.GH5609@e106622-lin> References: <1460438960-32060-1-git-send-email-bill.huey@gmail.com> <20160413085708.GB11651@pablo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2837 Lines: 76 On 13/04/16 02:37, Bill Huey (hui) wrote: > [Trying to resend this so that linux-kernel mailer doesn't reject it. > ok just found plain text mode. Will cull the CC list in future > responses] > > Hi Juri, > > It's not for replacing deadline first of all. I'm not fully aware of the > kind of things being done with deadline and I would like links so that I > have some kind of reference > OK. You can find references in Documentation, in my first reply and embedded in the ELC slides as well. Please, let me know if you need more :-). > The original motivation for doing this was for a number of reasons: > > 1) Current FIFO/RR policies aren't exact enough for a lot of the mixed > modern multimedia scenarios I saw working a real-world load on an Android > like system. Insufficient feedback to interactive UX tasks that include > things like jackd and pulse audio for low latency applications (music, > keyboard controllers, touch events...) across a span of tasks across the > system. > > Deadline seems to be more localized to a specific application's need and > seems to be hard to use but I'm inexperienced with it. The problems would > benefit from a simpler solution. > 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. > 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. > 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]. > 4) other reasons that should be in the docs but I got sick of writing > exhaustive documentation on the matter... > :-) > That's the best I can do for now. I need to post new version with > compilations fixes. There's a lot of problems with code regarding > portability and other issues with the initial revision. > OK. Feel free to ask if you also decide to experiment with DEADLINE and find any problem with it. Best, - Juri [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