From: "David Schwartz" <davids@webmaster.com>
To: <CFRIESEN@nortel.com>
Cc: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: CFS: some bad numbers with Java/database threading [FIXED]
Date: Wed, 19 Sep 2007 15:56:32 -0700
Message-ID: <MDEHLPKNGKAHNMBLJOLKEELFGOAC.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <46F17D03.9090801@nortel.com>
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1018
Lines: 28


> David Schwartz wrote:

> > Nonsense. The task is always ready-to-run. There is no reason
> > its CPU should
> > be low. This bug report is based on a misunderstanding of what yielding
> > means.

> The yielding task has given up the cpu.  The other task should get to
> run for a timeslice (or whatever the equivalent is in CFS) until the
> yielding task again "becomes head of the thread list".

Are you sure this isn't happening? I'll run some tests on my SMP system
running CFS. But I'll bet the context switch rate is quite rapid.

Honestly, I can't imagine what else could be happening here. Does CFS spin
in a loop doing nothing when you call sched_yield even though another task
is ready-to-run? That seems kind of bizarre. Is sched_yield acting as a
no-op?

DS


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