From: Peter Zijlstra <peterz@infradead.org>
To: Bruno Wolff III <bruno@wolff.to>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
Josh Boyer <jwboyer@redhat.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
Date: Tue, 22 Jul 2014 15:03:43 +0200 [thread overview]
Message-ID: <20140722130343.GD3935@laptop> (raw)
In-Reply-To: <20140722121001.GA30631@wolff.to>
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@infradead.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
next prev parent reply other threads:[~2014-07-22 13:03 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 14:55 Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c Bruno Wolff III
2014-07-16 15:17 ` Josh Boyer
2014-07-16 19:17 ` Dietmar Eggemann
2014-07-16 19:54 ` Bruno Wolff III
2014-07-16 23:18 ` Dietmar Eggemann
2014-07-17 3:09 ` Bruno Wolff III
2014-07-17 8:57 ` Dietmar Eggemann
2014-07-17 9:04 ` Peter Zijlstra
2014-07-17 11:23 ` Dietmar Eggemann
2014-07-17 12:35 ` Peter Zijlstra
2014-07-18 5:34 ` Bruno Wolff III
2014-07-18 9:28 ` Dietmar Eggemann
2014-07-18 12:09 ` Bruno Wolff III
2014-07-18 10:16 ` Peter Zijlstra
2014-07-18 13:01 ` Bruno Wolff III
2014-07-18 14:16 ` Dietmar Eggemann
2014-07-18 14:16 ` Peter Zijlstra
2014-07-18 14:50 ` Peter Zijlstra
2014-07-18 16:16 ` Peter Zijlstra
2014-07-21 16:35 ` Bruno Wolff III
2014-07-21 16:52 ` Peter Zijlstra
2014-07-22 9:47 ` Peter Zijlstra
2014-07-22 10:38 ` Peter Zijlstra
2014-07-22 12:10 ` Bruno Wolff III
2014-07-22 13:03 ` Peter Zijlstra [this message]
2014-07-22 13:26 ` Peter Zijlstra
2014-07-22 13:35 ` Peter Zijlstra
2014-07-22 14:09 ` Bruno Wolff III
2014-07-22 14:18 ` Peter Zijlstra
2014-07-23 1:37 ` Bruno Wolff III
2014-07-23 6:51 ` Peter Zijlstra
2014-07-22 17:05 ` H. Peter Anvin
2014-07-23 15:11 ` Peter Zijlstra
2014-07-23 15:12 ` H. Peter Anvin
2014-07-24 1:45 ` Bruno Wolff III
2014-07-23 15:39 ` [tip:x86/urgent] x86, cpu: Fix cache topology for early P4-SMT tip-bot for Peter Zijlstra
2014-07-22 12:12 ` Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c Dietmar Eggemann
2014-07-22 12:57 ` Bruno Wolff III
2014-07-28 8:28 ` [tip:sched/core] sched: Robustify topology setup tip-bot for Peter Zijlstra
2014-07-17 16:36 ` Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c Bruno Wolff III
2014-07-17 18:43 ` Dietmar Eggemann
2014-07-17 18:54 ` Bruno Wolff III
2014-07-17 4:21 ` Bruno Wolff III
2014-07-17 4:28 ` Bruno Wolff III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140722130343.GD3935@laptop \
--to=peterz@infradead.org \
--cc=bruno@wolff.to \
--cc=dietmar.eggemann@arm.com \
--cc=hpa@zytor.com \
--cc=jwboyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).