On 5/8/2024 7:40 AM, Dave Hansen wrote:
On 5/7/24 16:53, Chang S. Bae wrote:
However, due to resource constraints in storage, AMX state is excluded
from the scope of state recovery. Consequently, AMX state must be in its
initialized state for the IFS test to run.
This doesn't mention how this issue got introduced. Are we all bad at
reading the SDM? :)
Ah, I'd rather zap out this SDM sentence.
When AMX workloads are running, an active user AMX state remains even
after a context switch, optimizing to reduce the state reload cost. In
such cases, the test cannot proceed if it is scheduled.
This is a bit out of the blue. What does scheduling have do do with IFS?
$ echo <cpu#> > /sys/devices/virtual/misc/intel_ifs_0/run_test
Then,
run_test_store()
-> do_core_test()
-> ifs_test_core()
-> stop_core_cpuslocked()
-> stop_cpus()
-> queue_stop_cpus_work()
-> cpu_stop_queue_work()
-> wake_q_add()
-> wake_up_q()
So, the CPU stopper threads for <cpu#> and its sibling to execute
doscan() are queued up with the highest priority.
queue_stop_cpus_work() has
for_each_cpu(cpu, cpumask) {
work = &per_cpu(cpu_stopper.stop_work, cpu);
work->fn = fn;
work->arg = arg;
work->done = done;
work->caller = _RET_IP_;
if (cpu_stop_queue_work(cpu, work))
queued = true;
}
Those threads are created during early boot via
smpboot_register_percpu_thread().
I'm not sure those last two paragraphs add much value. I'd try to
banish most of that content to *after* you talk about the solution. Or
maybe put it in the cover letter.
It looks like lots of distractions coming from bunch of alternatives in
different levels.
Thanks,
Chang
PS: Let me respond the solution discussion separately. I do want to
experiment the init-track behavior a bit.
