Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757208AbZASTIt (ORCPT ); Mon, 19 Jan 2009 14:08:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753290AbZASTIj (ORCPT ); Mon, 19 Jan 2009 14:08:39 -0500 Received: from mx2.redhat.com ([66.187.237.31]:43805 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753205AbZASTIi (ORCPT ); Mon, 19 Jan 2009 14:08:38 -0500 Subject: RE: Mainline kernel OLTP performance update From: Steven Rostedt To: Chris Mason Cc: "Ma, Chinang" , Andrew Morton , Matthew Wilcox , "Wilcox, Matthew R" , "linux-kernel@vger.kernel.org" , "Tripathi, Sharad C" , "arjan@linux.intel.com" , "Kleen, Andi" , "Siddha, Suresh B" , "Chilukuri, Harita" , "Styner, Douglas W" , "Wang, Peter Xihong" , "Nueckel, Hubert" , "linux-scsi@vger.kernel.org" , Andrew Vasquez , Anirban Chakraborty , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Gregory Haskins , Rusty Russell In-Reply-To: <1232391305.6521.146.camel@think.oraclecorp.com> References: <20090114163557.11e097f2.akpm@linux-foundation.org> <20090115012147.GW29283@parisc-linux.org> <20090114180431.f4a96543.akpm@linux-foundation.org> <1231986439.21980.54.camel@localhost.localdomain> <1232388291.6521.140.camel@think.oraclecorp.com> <1232390259.25783.5.camel@localhost.localdomain> <1232391305.6521.146.camel@think.oraclecorp.com> Content-Type: text/plain Organization: Red Hat Date: Mon, 19 Jan 2009 14:07:35 -0500 Message-Id: <1232392055.25783.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1177 Lines: 29 On Mon, 2009-01-19 at 13:55 -0500, Chris Mason wrote: > I wasn't actually looking at the cost of the checks, even though they do > look higher (if they are using CONFIG_CPUMASK_OFFSTACK anyway). > > The 2.6.24 code would trigger a rescheduling interrupt only when the > prio of the inbound task was higher than the running task. > > This workload has a large number of equal priority rt tasks that are not > bound to a single CPU, and so I think it should trigger more > preempts/reschedules with the today's check_preempt_equal_prio(). Ah yeah. This is one of the things that shows RT being more "responsive" but less on performance. An RT task wants to run ASAP even if that means there's a chance of more interrupts and higher cache misses. The old way would be much faster in general through put, but I measured RT tasks taking up to tens of milliseconds to get scheduled. This is unacceptable for an RT task. -- Steve -- 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/