From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752789AbXCaKRc@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752789AbXCaKRc (ORCPT <rfc822;w@1wt.eu>);
	Sat, 31 Mar 2007 06:17:32 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752808AbXCaKRc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 31 Mar 2007 06:17:32 -0400
Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:41880 "EHLO
	fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752797AbXCaKRb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 31 Mar 2007 06:17:31 -0400
Date: Sat, 31 Mar 2007 19:15:13 +0900
Message-ID: <87wt0xhg7i.wl%takeuchi_satoru@jp.fujitsu.com>
From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>,
       Linux Kernel <linux-kernel@vger.kernel.org>,
       Ingo Molnar <mingo@elte.hu>
Subject: Re: [BUG] scheduler: strange behavor with massive interactive	processes
In-Reply-To: <1175071091.29829.58.camel@Homer.simpson.net>
References: <87r6rb1nbm.wl%takeuchi_satoru@jp.fujitsu.com>
	<1174971852.16403.35.camel@Homer.simpson.net>
	<1175071091.29829.58.camel@Homer.simpson.net>
User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8
 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu)
 MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Mike,

> I puttered around with your testcase a bit, and didn't see interactive
> tasks starving other interactive tasks so much as plain old interactive
> tasks starving expired tasks, which they're supposed to be able to do,

I inserted a trace code observing all context switches into the kernel and
confirmed that less than 10 processes having max prio certainly run
continuously and the others (having max - 1 prio) can run only at the
beggining of the program or when runqueue are expired (the chance is about
once a 200 secs in the 200 [procs/CPU] case, and their CPU time is deprived
in only 1 ticks) on each CPUs.

> Interactivity still seems to be fine with reasonable non-interactive
> loads despite ~reserving more bandwidth for non-interactive tasks.  Only
> lightly tested, YMMV, and of course the standard guarantee applies ;)

I've only seen your patch briefly and cant' make accurate comment yet. For
the time time being, however, I examined the test which is same as my initial
mail.

Test environment
================

 - kernel: 2.6.21-rc5 with or without Mike's patch
 - others: same as my initial mail except for omitting nice 19 cases

Result (without Mike's patch)
=============================

  +---------+-----------+------+------+------+--------+
  |   # of  |   # of    | avg  | max  | min  |  stdev |
  |   CPUs  | processes | (*1) | (*2) | (*3) |  (*4)  |
  +---------+-----------+------+------+------+--------+
  | 1(i386) |       200 |  162 | 8258 |    1 |   1113 |
  +---------+-----------+------+------+------+--------+
  |         |           |  378 | 9314 |    2 |   1421 |
  | 2(ia64) |       400 +------+------+------+--------+
  |         |           |  189 |12544 |    1 |   1443 |
  +---------+-----------+------+------+------+--------+

  *1) average number of loops among all processes
  *2) maximum number of loops among all processes
  *3) minimum number of loops among all processes
  *4) standard deviation

Result (with Mike's patch)
==========================

  +---------+-----------+------+------+------+--------+
  |   # of  |   # of    | avg  | max  | min  |  stdev |
  |   CPUs  | processes |      |      |      |        |
  +---------+-----------+------+------+------+--------+
  | 1(i386) |       200 |  154 | 1114 |    1 |    210 |
  +---------+-----------+------+------+------+--------+
  |         |           |  373 | 1328 |  108 |    246 |
  | 2(ia64) |       400 +------+------+------+--------+
  |         |           |  186 | 1169 |    1 |    211 |
  +---------+-----------+------+------+------+--------+

I also gatherd tha data, changing # of processors for the 1 CPU(i386):

  +---------+-----------+------+------+------+--------+
  |   # of  |   # of    | avg  | max  | min  |  stdev |
  |   CPUs  | processes |      |      |      |        |
  +---------+-----------+------+------+------+--------+
  |         |        25 | 1208 | 1787 |  987 |    237 |
  |         +-----------+------+------+------+--------+
  |         |        50 |  868 | 1631 |  559 |    275 |
  | 1(i386) +-----------+------+------+------+--------+
  |         |       100 |  319 | 1017 |   25 |    232 |
  |         +-----------+------+------+------+--------+
  |         |   200(*1) |  154 | 1114 |    1 |    210 |
  +---------+-----------+------+------+------+--------+

  *1) Same as the above table, just for easily comparison

It seems to highly depend on # of processes and at present, Ingo's patch
looks better.

Thanks,

Satoru