linux-kernel - Re: 2.6.21-rc3-mm1 RSDL results

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: <200703091936.47128.kernel@kolivas.org>
Date:	Fri, 9 Mar 2007 19:36:46 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	Matt Mackall <mpm@...enic.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org
Subject: Re: 2.6.21-rc3-mm1 RSDL results

On Friday 09 March 2007 18:53, Matt Mackall wrote:
> Well then I suppose something must be broken. When my box is idle, I
> can grab my desktop and spin it around and generate less than 25% CPU
> with the CPU stepped all the way down from 1.7GHz to 600MHz (Beryl is
> actually much snappier than many conventional window managers by doing
> just about everything through GL). By comparison, grabbing the Galeon
> scroll bar and wiggling it will generate 100% CPU (still throttled
> though) but remain relatively smooth.
>
> With a single non-parallel make running (all in cache, mind you), the
> system kicks up into just about 100% CPU usage at full speed. Desktop
> spinning becomes between 10x to 100x slower (from ~30fps to < 1fps).
> Galeon scrolling pauses for as much as a second. Mouse movement pauses
> for as much as a second. Typing in terminals lags noticeably.
>
> This is not the expected behavior of a fair, low-latency scheduler.

No indeed it does not sound right at all to me either. Last time I encountered 
something like this we traced it and hit sched_yield calls somewhere in the 
graphic pipeline. So first question is, how does mainline perform with the 
same testcase, and second question is umm whatever it is that is slow is 
there a way to trace it to see if it yields?

> For reference, this was with HZ=250, PREEMPT, PREEMPT_BKL, and !NO_HZ.

Ah I also wonder if it hasn't broken with NO_HZ. I haven't had a chance to 
even confirm that the code works properly with it, I was only assuming (after 
our last chat). See if turning that off makes a difference?

Thanks for testing!

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