From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758767Ab2IEMhH (ORCPT ); Wed, 5 Sep 2012 08:37:07 -0400 Received: from casper.infradead.org ([85.118.1.10]:53757 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751997Ab2IEMhG convert rfc822-to-8bit (ORCPT ); Wed, 5 Sep 2012 08:37:06 -0400 Message-ID: <1346848616.2600.26.camel@twins> Subject: Re: [tip:sched/core] sched: Fix load avg vs cpu-hotplug From: Peter Zijlstra To: paulmck@linux.vnet.ibm.com, mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org, rakib.mullick@gmail.com, tglx@linutronix.de Cc: linux-tip-commits@vger.kernel.org Date: Wed, 05 Sep 2012 14:36:56 +0200 In-Reply-To: References: <1345454817.23018.27.camel@twins> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2012-09-04 at 11:43 -0700, tip-bot for Peter Zijlstra wrote: > Commit-ID: f319da0c6894fcf55e21320e40506418a2aad629 > Gitweb: http://git.kernel.org/tip/f319da0c6894fcf55e21320e40506418a2aad629 > Author: Peter Zijlstra > AuthorDate: Mon, 20 Aug 2012 11:26:57 +0200 > Committer: Ingo Molnar > CommitDate: Tue, 4 Sep 2012 14:30:18 +0200 > > sched: Fix load avg vs cpu-hotplug > > Rabik and Paul reported two different issues related to the same few > lines of code. > > Rabik's issue is that the nr_uninterruptible migration code is wrong in > that he sees artifacts due to this (Rabik please do expand in more > detail). > > Paul's issue is that this code as it stands relies on us using > stop_machine() for unplug, we all would like to remove this assumption > so that eventually we can remove this stop_machine() usage altogether. > > The only reason we'd have to migrate nr_uninterruptible is so that we > could use for_each_online_cpu() loops in favour of > for_each_possible_cpu() loops, however since nr_uninterruptible() is the > only such loop and its using possible lets not bother at all. > > The problem Rabik sees is (probably) caused by the fact that by > migrating nr_uninterruptible we screw rq->calc_load_active for both rqs > involved. > > So don't bother with fancy migration schemes (meaning we now have to > keep using for_each_possible_cpu()) and instead fold any nr_active delta > after we migrate all tasks away to make sure we don't have any skewed > nr_active accounting. Oh argh.. this patch isn't actually right.. I actually removed it from my series but forgot to update the tarball. Ingo can you still make it go away or should I do a delta?