linux-kernel - Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c

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: <20140722130343.GD3935@laptop>
Date:	Tue, 22 Jul 2014 15:03:43 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Bruno Wolff III <bruno@...ff.to>
Cc:	Dietmar Eggemann <dietmar.eggemann@....com>,
	Josh Boyer <jwboyer@...hat.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Scheduler regression from
 caffcdd8d27ba78730d5540396ce72ad022aff2c

On Tue, Jul 22, 2014 at 07:10:01AM -0500, Bruno Wolff III wrote:
> On Tue, Jul 22, 2014 at 12:38:57 +0200,
>  Peter Zijlstra <peterz@...radead.org> wrote:
> >
> >Could you provide the output of cpuid and cpuid -r for your machine?
> >This code is magic and I've no idea what your machine is telling it to
> >do :/
> 
> I am attaching both sets of output. (I also added copies to the bug report.)

Thanks! and yes I now see (and I should have seen before) what is
'broken'.

>    0x00000000 0x00: eax=0x00000002 ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69

This gives us cpuid_level=0x02

>    0x00000002 0x00: eax=0x665b5001 ebx=0x00000000 ecx=0x00000000 edx=0x007b7040

Which means that init_intel_cacheinfo() will not use cpuid4 for
cacheinfo and we revert to cpuid2, which translates into:

>    cache and TLB information (2):
>       0x50: instruction TLB: 4K & 2M/4M pages, 64 entries
>       0x5b: data TLB: 4K & 4M pages, 64 entries
>       0x66: L1 data cache: 8K, 4-way, 64 byte lines
>       0x40: No L3 cache
>       0x70: Trace cache: 12K-uop, 8-way
>       0x7b: L2 cache: 512K, 8-way, sectored, 64 byte lines

Now the problem is that cpu_llc_id is only set on new_l[23], and set to
l[23]_id. Both new_l[23] and l[23]_id are only set in the cpuid4 case.

So for this P4 cpu_llc_id remains unset.

Furthermore cpuid2 does not include cpu masks, so we need to use cpuid1:

>    (multi-processing method): Intel leaf 1

>   0x00000001 0x00: eax=0x00000f29 ebx=0x0002080b ecx=0x00004400 edx=0xbfebfbff

to reconstruct the topology, with the added assumption that SMT threads
share all caches.

Oh, of course we do SMP detection and setup after the cache setup...
lovely.

/me goes bang head against wall

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