linux-kernel - RE: CFS: some bad numbers with Java/database threading [FIXED]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKGELIGOAC.davids@webmaster.com>
Date:	Wed, 19 Sep 2007 16:05:15 -0700
From:	"David Schwartz" <davids@...master.com>
To:	<CFRIESEN@...tel.com>
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: CFS: some bad numbers with Java/database threading [FIXED]

Chris Friesen wrote:

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

Yep, that's exactly what's happening. The tasks are alternating. They are
both always ready-to-run. The yielding task is put at the end of the queue
for its priority level.

There is no reason the yielding task should get less CPU since they're both
always ready-to-run.

The only downside here is that a yielding task results in very small
timeslices which causes cache inefficiencies. A sane lower bound on the
timeslice might be a good idea. But there is no semantic problem.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/