linux-kernel - Re: [BUG] 2.6.37-rc3 massive interactivity regression on ARM

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: <20101205162151.GH9138@n2100.arm.linux.org.uk>
Date:	Sun, 5 Dec 2010 16:21:51 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mikael Pettersson <mikpe@...uu.se>
Cc:	Venkatesh Pallipadi <venki@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [BUG] 2.6.37-rc3 massive interactivity regression on ARM

On Sun, Dec 05, 2010 at 05:07:36PM +0100, Mikael Pettersson wrote:
> I ran two tests on my iop32x machine:
> 
> 1. Made the above-mentioned assignment to rq->clock_task unconditional.
>    That cured the interactivity regressions.
> 
> 2. Restored the conditional assignment to rq->clock_task and disabled the
>    platform-specific sched_clock() so the kernel used the generic one.
>    That too cured the interactivity regressions.
> 
> I then repeated these tests on my ixp4xx machine, with the same results.
> 
> I'll try to come up with a fix for the ixp4xx and plat-iop 32-bit
> sched_clock()s.

I'm not sure that's the correct fix - it looks like sched_clock_cpu()
should already be preventing scheduler clock time going backwards.

Hmm. IOP32x seems to have a 32-bit timer clocked at 200MHz.  That means
it wraps once every 21s.  However, we have that converted to ns by an
unknown multiplier and shift.  It seems that those are chosen to
guarantee that we will cover only 4s without wrapping in the clocksource
conversion.  Maybe that's not sufficient?

Could you try looking into sched_clock_cpu(), sched_clock_local() and
sched_clock() to see whether anything odd stands out?
--
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/