Note that for memory, as I understand the documentation, it's less about "couldn't be run" than "couldn't have the real memory allocation necessary to avoid paging".

This is in contrast to another contended resource, memory bandwidth, "waiting" for which manifests at the process level as CPU cycles like any other code. It's possible to use profiling tools to distinguish memory waits from other CPU activity, but as far as I know nobody has built the infrastructure to bubble that data up in some form so it could be tracked systemically by the OS.

I can guess why: The memory hierarchy is complicated, and what you can derive about it from CPU performance counters is indirect and limited. Still, even some basic estimation for how many cache lines a process was responsible for driving over the memory bus would be helpful for those building high-performance systems and applications.