From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754695AbZLWLwV (ORCPT ); Wed, 23 Dec 2009 06:52:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754430AbZLWLwU (ORCPT ); Wed, 23 Dec 2009 06:52:20 -0500 Received: from casper.infradead.org ([85.118.1.10]:43003 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942AbZLWLwU (ORCPT ); Wed, 23 Dec 2009 06:52:20 -0500 Subject: Re: SCHED: Is task migration necessary in sched_exec(). From: Peter Zijlstra To: Rakib Mullick Cc: Ingo Molnar , LKML In-Reply-To: References: <1261563687.4937.120.camel@laptop> <1261565584.4937.124.camel@laptop> Content-Type: text/plain; charset="UTF-8" Date: Wed, 23 Dec 2009 12:51:52 +0100 Message-ID: <1261569112.4937.135.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2009-12-23 at 17:35 +0600, Rakib Mullick wrote: > Yes - current heuristics does this - to make sure that it doesn't have to > wait too long. It pushes process into another runqueue (probably less loaded) > just to make sure that - it will get the CPU a bit quickly. But when a task > got the CPU - we should keep it out of equation. The point of moving task > is - it have to wait less. At exec current task don't have to wait to get CPU. No, moving tasks isn't (primarily) about latency, it is about ensuring a fair proportion of service time. Do you have a particular workload you worry about or are you merely trying to satisfy your curiosity?