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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200703061815.16702.a1426z@gawab.com>
Date:	Tue, 6 Mar 2007 18:15:16 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Xavier Bestel <xavier.bestel@...e.fr>
Cc:	Markus Törnqvist <mjt@...v.org>,
	ck list <ck@....kolivas.org>, linux-kernel@...r.kernel.org,
	Con Kolivas <kernel@...ivas.org>
Subject: Re: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

Xavier Bestel wrote:
> On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> > Hah I just wish gears would go away. If I get hardware where it runs at
> > just the right speed it looks like it doesn't move at all. On other
> > hardware the wheels go backwards and forwards where the screen refresh
> > rate is just perfectly a factor of the frames per second (or something
> > like that).
> >
> > This is not a cpu scheduler test and you're inferring that there are cpu
> > scheduling artefacts based on an application that has bottlenecks at
> > different places depending on the hardware combination.
>
> I'd add that Xorg has its own scheduler (for X11 operations, of course),
> that has its own quirks, and chances are that it is the one you're
> testing with glxgears. And as Con said, as long as glxgears does more
> FPS than your screen refresh rate, its flickering its completely
> meaningless: it doesn't even attempt to sync with vblank. Al, you'd
> better try with Quake3 or Nexuiz, or even Blender if you want to test 3D
> interactivity under load.

Actually, games aren't really usefull to evaluate scheduler performance, due 
to their bursty nature.

OTOH, gears runs full throttle, including any of its bottlenecks. In fact, 
it's the bottlenecks that add to its realism.  It exposes underlying 
scheduler hickups visually, unless buffered by the display-driver, in which 
case you just use the vesa-driver to be sure.

If gears starts to flicker on you, just slow it down with a cpu hog like:

	# while :; do :; done &

Add as many hogs as you need to make the hickups visible.

Again, these hickups are only visible when using uneven nice+ levels.

BTW, another way to show these hickups would be through some kind of a 
cpu/proc timing-tracer.  Do we have something like that?


Thanks!

--
Al

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ