Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754670Ab2BARHW (ORCPT ); Wed, 1 Feb 2012 12:07:22 -0500 Received: from mail-yw0-f46.google.com ([209.85.213.46]:57048 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753552Ab2BARHU convert rfc822-to-8bit (ORCPT ); Wed, 1 Feb 2012 12:07:20 -0500 MIME-Version: 1.0 In-Reply-To: <1328104527.2662.4.camel@laptop> References: <1327854877.8504.3.camel@localhost.localdomain> <20120131084830.GA22077@linux.vnet.ibm.com> <1328104527.2662.4.camel@laptop> Date: Wed, 1 Feb 2012 23:07:20 +0600 Message-ID: Subject: Re: [PATCH] sched: At sched_fork use __set_task_cpu(). From: Rakib Mullick To: Peter Zijlstra Cc: Kamalesh Babulal , mingo@elte.hu, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1652 Lines: 38 On Wed, Feb 1, 2012 at 7:55 PM, Peter Zijlstra wrote: > On Tue, 2012-01-31 at 14:18 +0530, Kamalesh Babulal wrote: >> * Rakib Mullick [2012-01-29 22:34:37]: >> >> > ?We don't use select_task_rq() from sched_fork() anymore and no chance of task gets migrated at >> > this point. Therefore, we can avoid task migration related checking/accounting, so use >> > __set_task_cpu() instead of set_task_cpu(). >> > >> > Signed-off-by: Rakib Mullick >> ? Reviewed-by: Kamalesh Babulal > > Since we call sched_fork() with preemption enabled _long_ after the > child is copied from the parent who is to say we (parent) didn't migrate > away and are now setting a different cpu? > If parent gets migrated that should be accounted as parents migration count not for child offcourse. And if we're counting child's nr_migration count for parent's getting migrated, we're simply screwing childs migration count. Isn't it? > One could argue that that might not be a real migration from the child's > POV, maybe, but nobody seems to be making that argument. > But I'm not seeing it from child's or parent's POV. I'm simply addressing the point of a task's migration counter (p->se.nr_migrations), simply this task wasn't moved. > I really don't see the point of this.. > I'm hoping, you'll rethink... Thanks, Rakib -- 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/