3 ms·

Peter did admit his mistake about superfetch (he thought the xpnet thing was counting that too as used memory), but he's still right about the overall metric be

by sid0 17y ago

Peter did admit his mistake about superfetch (he thought the xpnet thing was counting that too as used memory), but he's still right about the overall metric being wrong -- see the comments to http://exo-blog.blogspot.com/2010/02/editorial-what-took-you-so-long.html http://exo-blog.blogspot.com/2010/02/editorial-what-took-you... . edit: and do you think he doesn't know about procexp/perfmon? :)

barrkel 17y ago
Why do you insist on making this personal? I discounted an article, not a person. By bringing the person into this, you turn it into an irrational, emotional thing, where facts don't matter. That's not where you want to be. And at the risk of extending this thing far beyond its worthy lifetime, that comment you link to proves very little. As I already said: > Committed Bytes would be a measure of potential maximum physical memory usage if every process were touching every page that it had available to it. Yes, no process ever does that, but statistically there will be an average fraction of that memory which is touched, so it can be interpreted as a proxy for physical memory pressure. A poor one though, as different processes have different patterns. Allocating a huge bunch of memory and not touching it is one statistical pattern, but it's not particularly common, which is key. It's an outlier, so it isn't strong evidence. On average, committed bytes can be interpreted as a proxy for memory pressure, but like I said, there's likely to be a fair amount of variance there, so it's a poor proxy. There certainly wouldn't be a 1:1 relationship between committed memory and physical memory pressure; if I had to guess, I would guess somewhere like 60% of committed memory should ideally be in physical ram. For example, my machine has 12GB of RAM, 3.5GB committed bytes total and 2.5GB working set total. But that working set includes both private and shared working set pages - calculating the active working set properly would require dividing shared page sizes by the number of copies in different processes. But just for fun, I plotted the log of working set values in MB along the X axis, and the log of private bytes in MB along the Y axis, for each process, and this is what I got: http://imgurl.filetac.com/img/68343980.png http://imgurl.filetac.com/img/68343980.png Looks like a pretty close correlation to me - yes, there are some spikes in private bytes, but on average, private bytes is a proxy for committed bytes (I excluded shared pages for confounding reasons, as they are usually things like EXEs and DLLs - not counted against commit charge), committed bytes is a proxy for physical memory usage, which in turn is a proxy for physical memory pressure.

by sid0 17y ago

barrkel 17y ago

Why do you insist on making this personal? I discounted an article, not a person. By bringing the person into this, you turn it into an irrational, emotional thing, where facts don't matter. That's not where you want to be. And at the risk of extending this thing far beyond its worthy lifetime, that comment you link to proves very little. As I already said: > Committed Bytes would be a measure of potential maximum physical memory usage if every process were touching every page that it had available to it. Yes, no process ever does that, but statistically there will be an average fraction of that memory which is touched, so it can be interpreted as a proxy for physical memory pressure. A poor one though, as different processes have different patterns. Allocating a huge bunch of memory and not touching it is one statistical pattern, but it's not particularly common, which is key. It's an outlier, so it isn't strong evidence. On average, committed bytes can be interpreted as a proxy for memory pressure, but like I said, there's likely to be a fair amount of variance there, so it's a poor proxy. There certainly wouldn't be a 1:1 relationship between committed memory and physical memory pressure; if I had to guess, I would guess somewhere like 60% of committed memory should ideally be in physical ram. For example, my machine has 12GB of RAM, 3.5GB committed bytes total and 2.5GB working set total. But that working set includes both private and shared working set pages - calculating the active working set properly would require dividing shared page sizes by the number of copies in different processes. But just for fun, I plotted the log of working set values in MB along the X axis, and the log of private bytes in MB along the Y axis, for each process, and this is what I got: http://imgurl.filetac.com/img/68343980.png http://imgurl.filetac.com/img/68343980.png Looks like a pretty close correlation to me - yes, there are some spikes in private bytes, but on average, private bytes is a proxy for committed bytes (I excluded shared pages for confounding reasons, as they are usually things like EXEs and DLLs - not counted against commit charge), committed bytes is a proxy for physical memory usage, which in turn is a proxy for physical memory pressure.