From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756462AbXG1Tfj (ORCPT ); Sat, 28 Jul 2007 15:35:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753794AbXG1Tfc (ORCPT ); Sat, 28 Jul 2007 15:35:32 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:50178 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753227AbXG1Tfc (ORCPT ); Sat, 28 Jul 2007 15:35:32 -0400 Date: Sat, 28 Jul 2007 12:34:57 -0700 (PDT) From: Linus Torvalds To: Jan Engelhardt cc: Kasper Sandberg , Linux Kernel Mailing List , Ingo Molnar , CK Mailinglist Subject: Re: Linus 2.6.23-rc1 In-Reply-To: Message-ID: References: <1185588279.1654.1.camel@localhost> <1185615848.13701.16.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 28 Jul 2007, Jan Engelhardt wrote: > > Time to investigate... Well, one thing that would be worth doing is to simply create a trace of time-slices for both schedulers. It could easily be some hacky thing that just saves the process name and TSC at each scheduling event in some fairly small fixed-sized per-CPU circular buffer, and have a /sys interface that reads it out, and then you do sleep 60 ; cat /sys/cpubuffer > buffer and play the game for 60 seconds (so that you get a buffer that represents perhaps the last 10 seconds of play). It could *literally* just be an effect of the time quanta used, and CFS just deciding that it's not interactive and giving things too long of a CPU slice. Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to tweak, but maybe there's some misfeature there, or maybe the default is just bad for games, or whatever. Ingo: that sysctl_sched_granularity initialization doesn't make sense. You talk about it being in units of nanoseconds, but then you do 2000000000ULL/HZ which is nonsensical. That value is "2 seconds" (not 2ms like the comment says) in nanoseconds, but then divided by HZ, so what's the meaning of that HZ thing? Nothing in the scheduler should care about jiffies, why is that related to HZ? All the scheduler clocks are in ns. Linus