From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753612Ab2CZTaF (ORCPT ); Mon, 26 Mar 2012 15:30:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40512 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753120Ab2CZTaD (ORCPT ); Mon, 26 Mar 2012 15:30:03 -0400 Message-ID: <4F70C365.8020009@redhat.com> Date: Mon, 26 Mar 2012 15:28:37 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Zijlstra CC: Andrea Arcangeli , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hillf Danton , Dan Smith , Linus Torvalds , Andrew Morton , Thomas Gleixner , Ingo Molnar , Paul Turner , Suresh Siddha , Mike Galbraith , "Paul E. McKenney" , Lai Jiangshan , Bharata B Rao , Lee Schermerhorn , Johannes Weiner Subject: Re: [PATCH 11/39] autonuma: CPU follow memory algorithm References: <1332783986-24195-1-git-send-email-aarcange@redhat.com> <1332783986-24195-12-git-send-email-aarcange@redhat.com> <1332786353.16159.173.camel@twins> In-Reply-To: <1332786353.16159.173.camel@twins> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/26/2012 02:25 PM, Peter Zijlstra wrote: > On Mon, 2012-03-26 at 19:45 +0200, Andrea Arcangeli wrote: >> @@ -3220,6 +3214,8 @@ need_resched: >> >> post_schedule(rq); >> >> + sched_autonuma_balance(); >> + >> sched_preempt_enable_no_resched(); >> if (need_resched()) >> goto need_resched; > > I already told you, this isn't ever going to happen. You do _NOT_ put a > for_each_online_cpu() loop in the middle of schedule(). Agreed, it looks O(N), but because every CPU will be calling it its behaviour will be O(N^2) and has the potential to completely break systems with a large number of CPUs. Finding a lower overhead way of doing the balancing does not seem like an unsurmountable problem. > You also do not call stop_one_cpu(migration_cpu_stop) in schedule to > force migrate the task you just scheduled to away from this cpu. That's > retarded. > > Nacked-by: Peter Zijlstra -- All rights reversed