linux-kernel - Re: CFS review

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: <1188374249.21502.155.camel@koto.keithp.com>
Date:	Wed, 29 Aug 2007 00:57:29 -0700
From:	Keith Packard <keith.packard@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	keith.packard@...el.com, Al Boldi <a1426z@...ab.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Mike Galbraith <efault@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: CFS review

On Wed, 2007-08-29 at 06:46 +0200, Ingo Molnar wrote:

> ok, i finally managed to reproduce the "artifact" myself on an older 
> box. It goes like this: start up X with the vesa driver (or with NoDRI) 
> to force software rendering. Then start up a couple of glxgears 
> instances. Those glxgears instances update in a very "chunky", 
> "stuttering" way - each glxgears instance runs/stops/runs/stops at a 
> rate of a about once per second, and this was reported to me as a 
> potential CPU scheduler regression.

Hmm. I can't even run two copies of glxgears on software GL code today;
it's broken in every X server I have available. Someone broke it a while
ago, but no-one noticed. However, this shouldn't be GLX related as the
software rasterizer is no different from any other rendering code.

Testing with my smart-scheduler case (many copies of 'plaid') shows that
at least with git master, things are working as designed. When GLX is
working again, I'll try that as well.

> at a quick glance this is not a CPU scheduler thing: X uses up 99% of 
> CPU time, all the glxgears tasks (i needed 8 parallel instances to see 
> the stallings) are using up the remaining 1% of CPU time. The ordering 
> of the requests from the glxgears tasks is X's choice - and for a 
> pathological overload situation like this we cannot blame X at all for 
> not producing a completely smooth output. (although Xorg could perhaps 
> try to schedule such requests more smoothly, in a more finegrained way?)

It does. It should switch between clients ever 20ms; that's why X spends
so much time asking the kernel for the current time.

Make sure the X server isn't running with the smart scheduler disabled;
that will cause precisely the symptoms you're seeing here. In the normal
usptream sources, you'd have to use '-dumbSched' as an X server command
line option.

The old 'scheduler' would run an entire X client's input buffer dry
before looking for requests from another client. Because glxgears
requests are small but time consuming, this can cause very long delays
between client switching.

-- 
keith.packard@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)