Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755440Ab2HROsI (ORCPT ); Sat, 18 Aug 2012 10:48:08 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:43869 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751941Ab2HROsE (ORCPT ); Sat, 18 Aug 2012 10:48:04 -0400 Date: Sat, 18 Aug 2012 07:46:59 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Alessio Igor Bogani , Andrew Morton , Avi Kivity , Chris Metcalf , Christoph Lameter , Geoff Levand , Gilad Ben Yossef , Hakan Akkan , "H. Peter Anvin" , Ingo Molnar , Kevin Hilman , Max Krasnyansky , Peter Zijlstra , Stephen Hemminger , Steven Rostedt , Sven-Thorsten Dietrich , Thomas Gleixner , LKML Subject: Re: Status of adaptive tickless patchset as of august 2012 Message-ID: <20120818144659.GB3533@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20120818140248.GA16073@somewhere.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120818140248.GA16073@somewhere.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12081814-7408-0000-0000-000007B9957D Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4241 Lines: 87 On Sat, Aug 18, 2012 at 04:02:51PM +0200, Frederic Weisbecker wrote: > Hi, > > I started working on the adaptive nohz patchset by the end of 2010. Since then, I > iterated through one big branch: > > - Nohz tasks (https://lwn.net/Articles/420490/) > - Nohz cpusets (https://lwn.net/Articles/455044/) > - Nohz cpusets v2 (https://lwn.net/Articles/487599/) > - Nohz cpusets v3 (https://lwn.net/Articles/495422/) > > It quickly grew up to more than 40 patches. And still the full support > (ie: handle everything that the tick maintains, but without the tick) wasn't > yet finished. > > And the more I was progressing to get this full support, the more I had patches to > maintain, rebase, improve, etc... > > Some side effects went to increase: > > - I had deep reviews about the core overall design in the first iterations. Thanks > to that I made nice progresses. But as the patchset grew, I got less reviews about > overall design but more about details. And I can totally understand that. Huge pile > of patches certainly don't encourage reviews. > > - Lacking reviews on the overall design, I was feeling more and more uncomfortable about > whatever I was improving or whichever feature I was adding on top of the existing ones. > And I was indeed digging on some wrong direction for some parts. > > - I was spending too much time in out-of-tree maintainance while my goal is to get this > upstream. > > All in one, this big branch neither scaled in term of reviews nor development. > > So I decided, after Ingo proposed me to set a tree in -tip, to cut all of the things the > tick is handling and isolate each of these into single separate topics and handle them > individually or at least iteratively, trying to push the things upstream or in a staging > tree in -tip piecewise. As long as this is carried by concerned maintainers and I can get > their insights on a regular basis. And also as long as we can iterate to some central branch > because, even if we can cut out things into individual topics, there are significant interdependencies. > > I think this has been successfull so far: > > - The detection of illegal RCU read side critical sections under RCU extended quiescent > state is now upstream. This even helped finding lot of bugs upstream. > > - State of user as RCU extended quiescent state is currently pending in Paul's tree > in the rcu/idle branch. It's also in linux-next. This may likely go upstream or in > a staging branch in -tip for the next merge window. Indeed, the current plan is to push it for 3.7. ;-) Thanx, Paul > - Some preparatory work to split nohz and idle logic in nohz API. It went upstream > on the last merge window. > > - Proposed something to handle nohz cputime accounting: https://lwn.net/Articles/501766/ > Got fundamental reviews that pointed me to rather reuse virtual based cputime accounting. > > - Consolidated/cleaned up virtual based cputime accounting (last version is > https://lkml.org/lkml/2012/8/17/326 and waits for inclusion in -tip or so.) > > - On top of that vtime consolidation and the RCU pending patches, propose > a generic virtual cputime accounting for archs that don't have CONFIG_VTIME_CPU_ACCOUNTING. > See http://comments.gmane.org/gmane.linux.kernel/1337690 > A tickless CPU can then account cputime with that. > > So the process seem to be in a better direction now. Summer holidays have naturally made it a > bit smoother and the rythm will probably stay that way until the end of ksummit/linuxcon/LPC. But > I have the feeling we are moving forward. > > No schedule plans, but once I get the above topics sorted out, I'll probably work on timekeeping > handling in adaptive tickless CPUs. And then the rest... > > I'll still keep maintaining the big branch in my tree. But this is now going to be rather a big draft or > laboratory, with regular rebases on what is merged upstream or in maintainers tree. It helps me to > keep a practical view of the big picture. > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/