Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966062AbcDMJha (ORCPT ); Wed, 13 Apr 2016 05:37:30 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:34298 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965155AbcDMJh1 (ORCPT ); Wed, 13 Apr 2016 05:37:27 -0400 MIME-Version: 1.0 In-Reply-To: <20160413085708.GB11651@pablo> References: <1460438960-32060-1-git-send-email-bill.huey@gmail.com> <20160413085708.GB11651@pablo> Date: Wed, 13 Apr 2016 02:37:26 -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 , KY Srinivasan , Amir Frenkel , Bdale Garbee , 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: 1613 Lines: 39 [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 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. 2) The need for a scheduler to be driven by an external interrupt from a number sources directly. 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... 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. bill