Go having a rather sophisticated and complex scheduler to begin with suggests to me that you would be better off conducting your experiments in a vastly simplified setting, say with just a simple single C (Zig?) process with the minimal possible count of CPUs to observe in your experiments.
Also you will want to account for the kernel's tendency to reactively move pages closer (NUMA wise) to where they are used-- this may be on or off on your Linux distribution by default, and it will definitely impact your measurements. Also you will need to read up on how to know if memory is actually still far away, since your TLB can have the same virtual memory address for a near or a far physical page. It's not possible, as far as I understand, to pin TLB entries without kernel level privilege. Thus experiments are pretty hard to do to begin with. Start simple. Get reproducibility. Get a positive control. Advance from there. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/800819b8-e255-4db5-bb68-3a39e39b1420n%40googlegroups.com.
