From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760604AbXJaWF5 (ORCPT ); Wed, 31 Oct 2007 18:05:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761542AbXJaWFF (ORCPT ); Wed, 31 Oct 2007 18:05:05 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:44588 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761529AbXJaWFB (ORCPT ); Wed, 31 Oct 2007 18:05:01 -0400 Subject: Re: [PATCH 3/6] sched: high-res preemption tick From: Peter Zijlstra To: Andi Kleen Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Mike Galbraith , Dmitry Adamushko , Thomas Gleixner In-Reply-To: References: <20071031211030.310581000@chello.nl> <20071031211249.142859000@chello.nl> Content-Type: text/plain Date: Wed, 31 Oct 2007 23:04:31 +0100 Message-Id: <1193868271.5911.5.camel@lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2007-10-31 at 22:53 +0100, Andi Kleen wrote: > Peter Zijlstra writes: > > > Use HR-timers (when available) to deliver an accurate preemption tick. > > > > The regular scheduler tick that runs at 1/HZ can be too coarse when nice > > level are used. The fairness system will still keep the cpu utilisation 'fair' > > by then delaying the task that got an excessive amount of CPU time but try to > > minimize this by delivering preemption points spot-on. > > This might be costly when hrtimers happen to use an more expensive > to reprogram time source. Even an APIC timer access is fairly slow. > And you'll potentially add the to lots of context switces. > > Not sure that is a good idea for performance in general. Well, me neither, it was just an idea, and a challenge to get working :-)