Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265039AbTCEKjF>; Wed, 5 Mar 2003 05:39:05 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265250AbTCEKjF>; Wed, 5 Mar 2003 05:39:05 -0500
Received: from [195.71.209.2] ([195.71.209.2]:16395 "HELO ns2.ontika.net")
	by vger.kernel.org with SMTP id <S265039AbTCEKjE>;
	Wed, 5 Mar 2003 05:39:04 -0500
Message-ID: <3E65D61A.8070508@ontika.net>
Date: Wed, 05 Mar 2003 11:48:58 +0100
From: Kai Bankett <chaosman@ontika.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kamble, Nitin A" <nitin.a.kamble@intel.com>
CC: linux-kernel@vger.kernel.org, kai.bankett@ontika.net, mingo@redhat.com,
       akpm@diago.com, "Nakajima, Jun" <jun.nakajima@intel.com>,
       "Mallick, Asit K" <asit.k.mallick@intel.com>,
       "Saxena, Sunil" <sunil.saxena@intel.com>
Subject: Re: [PATCH][IO_APIC] 2.5.63bk7 irq_balance improvments / bug-fixes
References: <E88224AA79D2744187E7854CA8D9131DA8B7DE@fmsmsx407.fm.intel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1176
Lines: 33

>
>
>  2. Or move the heavy imbalance around all the cpus in the round robin 
>     fashion at high rate.
>
>
>Both the solutions will eliminate the bouncing behavior. The current 
>implementation is based on the option 2, with the only difference of 
>lower rate of distribution (5 sec).  The optimal option is workload 
>dependant. With static and heavy interrupt load, the option 2 looks 
>better, while with random interrupt load the option 1 is good enough.
>
>  
>
Hi Nitin,

Thanks much for your response !
Are you really sure that option 2 looks better on a static and heavy 
interrupt load ?
If the load is generated by few heavy sources (sources_count < 
count(cpus)) why not distributed them (mostly) statically across the 
available cpus ? What gain do you have by rotating them round robin in 
this case ?
I think round robin only starts making sense if the number of heavy 
sources is > number of physical cpus.

Kai

-
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/