When you start a parpool, MATLAB asks the scheduler to run however-many tasks. It is up to the operating system scheduler as to whether those threads are assigned to otherwise-unused physical cores, or to physical cores shared with random other tasks (such as browser updates), or to physical cores shared between multiple MATLAB processes.
MATLAB does not use operating system "lock process to core" calls.
Typically operating systems automatically assign new tasks to one or two shared cores, and then typically operating systems fairly soon migrate computation tasks to physical cores that are not currently busy. Typically operating systems do not assign tasks as hyperthreads to shared cores when there are available unshared cores.
So typically if you run 128 computation processes, then most of the processes will end up fairly quickly migrated to unshared physical cores.
However... if you are running as many computation processes as there are physical cores, then there will end up being a resource conflict for a few cores, as there is almost always background work that needs to be done (such as browser updates, checking mail, anti-virus work, disk and other resource management.) When there are more active processes than there are physical cores, some processes might end up sharing a physical core by using hyperthreading (unless you have hyperthreading turned off in the BIOS), and other processes might end up temporarily swapped out in a non-hyperthreaded way while a physical core is busy doing other work. I do not presently have any information as to how operating systems decide whether to swap processes or hyperthread.
On Linux, you can set CPU affinity using taskset . Potentially you could make a taskset part of SLURM setup -- but be careful not to lock all processors due to the need to run background processes.
