Date: Tue, 21 Aug 2007 12:58:58 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Al Boldi <a1426z@gawab.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Mike Galbraith <efault@gmx.de>,
       Andrew Morton <akpm@linux-foundation.org>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       linux-kernel@vger.kernel.org
Subject: Re: CFS review
Message-ID: <20070821105858.GC26598@elte.hu>
References: <200708111344.42934.a1426z@gawab.com> <200708121827.36656.a1426z@gawab.com> <20070812155242.GA1977@elte.hu> <200708122243.05191.a1426z@gawab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200708122243.05191.a1426z@gawab.com>
User-Agent: Mutt/1.5.14 (2007-02-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1236
Lines: 32


* Al Boldi <a1426z@gawab.com> wrote:

> There is one workload that still isn't performing well; it's a 
> web-server workload that spawns 1K+ client procs.  It can be emulated 
> by using this:
> 
>   for i in `seq 1 to 3333`; do ping 10.1 -A > /dev/null & done

on bash i did this as:

  for ((i=0; i<3333; i++)); do ping 10.1 -A > /dev/null & done

and this quickly creates a monster-runqueue with tons of ping tasks 
pending. (i replaced 10.1 with the IP of another box on the same LAN as 
the testbox) Is this what should happen?

> The problem is that consecutive runs don't give consistent results and 
> sometimes stalls.  You may want to try that.

well, there's a natural saturation point after a few hundred tasks 
(depending on your CPU's speed), at which point there's no idle time 
left. From that point on things get slower progressively (and the 
ability of the shell to start new ping tasks is impacted as well), but 
that's expected on an overloaded system, isnt it?

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