From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754154AbXDXPGS (ORCPT ); Tue, 24 Apr 2007 11:06:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754170AbXDXPGR (ORCPT ); Tue, 24 Apr 2007 11:06:17 -0400 Received: from mga03.intel.com ([143.182.124.21]:24182 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754154AbXDXPGQ (ORCPT ); Tue, 24 Apr 2007 11:06:16 -0400 X-ExtLoop1: 1 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="218704496:sNHT20143662" Date: Fri, 20 Apr 2007 13:11:01 -0700 From: "Siddha, Suresh B" To: William Lee Irwin III Cc: Christoph Lameter , Ingo Molnar , linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Con Kolivas , Nick Piggin , Mike Galbraith , Arjan van de Ven , Peter Williams , Thomas Gleixner , caglar@pardus.org.tr, Willy Tarreau , Gene Heskett Subject: Re: [patch] CFS scheduler, v3 Message-ID: <20070420201101.GC5475@linux-os.sc.intel.com> References: <20070418175017.GA5250@elte.hu> <20070418212645.GU2986@holomorphy.com> <20070420192906.GB2986@holomorphy.com> <20070420193856.GC2986@holomorphy.com> <20070420200322.GD2986@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070420200322.GD2986@holomorphy.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2007 at 01:03:22PM -0700, William Lee Irwin III wrote: > On Fri, 20 Apr 2007, William Lee Irwin III wrote: > >> I'm not really convinced it's all that worthwhile of an optimization, > >> essentially for the same reasons as you, but presumably there's a > >> benchmark result somewhere that says it matters. I've just not seen it. > > On Fri, Apr 20, 2007 at 12:44:55PM -0700, Christoph Lameter wrote: > > If it is true that we frequently remotely write the per cpu runqueue > > data then we may have a NUMA scalability issue. > > From the discussion on Suresh's thread, it appears to have sped up a > database benchmark 0.5%. > > Last I checked it was workload-dependent, but there were things that > hammer it. I mostly know of the remote wakeup issue, but there could > be other things besides wakeups that do it, too. remote wakeup was the main issue and the 0.5% improvement was seen on a two node platform. Aligning it reduces the number of remote cachelines that needs to be touched as part of this wakeup. thanks, suresh