Date: Wed, 23 Feb 2022 00:46:08 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Motin <mav@freebsd.org> Cc: Mike Karels <mike@karels.net>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, "Chen, Alvin W" <Weike.Chen@dell.com>, freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: <YhVnsB5ZwLYmpAFP@kib.kiev.ua> In-Reply-To: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> References: <PH0PR19MB4938FC8E343F7AA23F66C7439E349@PH0PR19MB4938.namprd19.prod.outlook.com> <PH0PR19MB4938BC329E905FA3BFC93EBB9E359@PH0PR19MB4938.namprd19.prod.outlook.com> <PH0PR19MB49388A4BC14B16FCEA5F742D9E359@PH0PR19MB4938.namprd19.prod.outlook.com> <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <bc01426a-9750-a161-0bfa-e1acd5299f81@FreeBSD.org> <YhE1rWoA%2BhMfebq/@kib.kiev.ua> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 19, 2022 at 07:26:24PM -0500, Alexander Motin wrote:
> On 19.02.2022 13:23, Konstantin Belousov wrote:
> > On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote:
> > > On 19.02.2022 12:02, Mike Karels wrote:
> > > > On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote:
> > > > > Just a thought, but can it be the reason with timing (e.g., rendezvous
> > > > > within (i)threads, hardware controlls without using hardware timer)
> > > > > problem?
> > > > >
> > > > > On FreeBSD, IIUC, multi processor (multi core) implementation assumes
> > > > > SMP (differs only clock speed) and end up with difference of
> > > > > performance at same clock speed within P-core and E-core, possibly.
> > > >
> > > > Another possibility is that the system is confused by having hyperthreading
> > > > on the P cores but not the E cores.
> > >
> > > No, I've tried to disable SMT and different number of cores to make it look
> > > identical and uniform for the scheduler. The only thing I could not test is
> > > disabling all P cores to test only E, the motherboard does not allow that,
> > > requiring at least one P core enabled.
> >
> > Does the kernel select MWAIT as the idle method? If you set idle to spin,
> > is anything change?
>
> By default kernel selects ACPI, using MWAIT:
> machdep.idle: acpi
> dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc
>
> I've tried to do in loader:
> set machdep.idle_mwait=0
> set machdep.idle="spin" (also tried "hlt")
> , but without visible positive effects.
I was only interested in spin, for hlt there is no chance if spin did not
worked.
Ok, the next step is to get the CPU feature reports from P- vs. E- cores.
Patch below should work, with verbose boot.
diff --git a/sys/x86/x86/identcpu.c b/sys/x86/x86/identcpu.c
index 849f532dbf8b..9e4da4722f77 100644
--- a/sys/x86/x86/identcpu.c
+++ b/sys/x86/x86/identcpu.c
@@ -246,7 +246,7 @@ printcpuinfo(void)
u_int regs[4], i;
char *brand;
- printf("CPU: ");
+ printf("CPU %d: ", PCPU_GET(cpuid));
#ifdef __i386__
cpu_class = cpus[cpu].cpu_class;
strncpy(cpu_model, cpus[cpu].cpu_name, sizeof (cpu_model));
diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
index 3b0e25172d0d..4299eb5348e6 100644
--- a/sys/x86/x86/mp_x86.c
+++ b/sys/x86/x86/mp_x86.c
@@ -1089,7 +1089,7 @@ init_secondary_tail(void)
load_es(_udatasel);
load_fs(_ufssel);
#endif
-
+printcpuinfo();
mtx_unlock_spin(&ap_boot_mtx);
/* Wait until all the AP's are up. */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YhVnsB5ZwLYmpAFP>