Talk:Commit charge

Tidy it up first

This article first needs to be tidied up. It's pretty messy, and it has information in one paragraph when it should be in another. --Gary King 17:32, 11 December 2005 (UTC)

Absolutely correct. I just did a "brain dump" to get the facts down quickly (and correct errors in the previous version) but haven't had time to get back to it. It's tough to provide a useful explanation of what "commit charge" really is without explaining most of the Windows memory management subsystem... Jeh 11:36, 12 December 2005 (UTC)

Notability

I found this page useful. Yet it does not appear to qualify as notable under WP:N. But, as a good-faith contributor to Wikipedia, respecting the consensus, I have flagged it as potentially non-notable.

Specifically, I believe it does have significant coverage, from reliable sources, but in this case that coverage is not from sources that are independent of the topic (they're from Microsoft Press). I also believe that significant coverage that is independent from Microsoft is unlikely, due to the specific nature of the topic.

But I found the page useful. I wanted to know what commit charge meant, and this page did a damn fine job of explaining it. And it is encyclopaedic content, reliably sourced. This is a good example of why I support the reconsideration of the notability guideline.

Well, 'reliably' if you consider anything Microsoft says is 'reliable'... —Preceding unsigned comment added by 134.161.227.84 (talk) 19:53, 11 August 2009 (UTC)

Seems a bit hasty to flag this for deletion. It is an article I refer to regularly. So I'd consider it noteworthy. I certainly be very disappointed to see it deleted... Felixcatuk 09:49, 9 August 2007 (UTC)

Well thanks! :) Jeh 20:32, 9 August 2007 (UTC)

Same here. Unfortunately, being useful, reliable and encyclopaedic doesn't seem to be enough on Wikipedia. It also appears that topics need to be notable. See the content guideline on notability: Wikipedia:Notability. I don't agree with it, but refusing to act on it, or acting on it only selectively, seems to me to offer two problems: One, people will use the policy to selectively achieve ends that have little or nothing to do with the intent or intended outcome of the policy; and, two, the policy is less likely to be improved because everybody is happy enough "just living with it". -- BenBildstein 04:39, 14 August 2007 (UTC)

"Specifically, I believe it does have significant coverage, from reliable sources, but in this case that coverage is not from sources that are independent of the topic (they're from Microsoft Press)." Hm, there should be some reliable third party sources in the form of Mark Russinovich's articles for whatever magazine he was writing for, before he was hired by MS. Also, possibly, some items from his blog, again before he was hired from MS. Can anyone dig those up?

Jeh 06:01, 14 August 2007 (UTC)

The subject's inherent notability comes from the fact that this article describes something that is currently in use on several hundred million computers. As to the references we're using, User:Jeh is a bit confused. Both books were written by David A. Solomon and Mark Russinovich, and the fact that the books were published by Microsoft Press doesn't mean that they're authoritative Microsoft publications -- see Code Complete for an example. Considering that Solomon & Russinovich have been highly regarded experts in the field of Windows NT internals for many years, these books pass Wikipedia's WP:N requirements. I own the latter book, so I can confirm that the information is accurate.

Consequently, I've removed the {{notability}} tag. It really isn't appropriate here.

-/- Warren 06:47, 14 August 2007 (UTC)

Being in use on several hundred million computers isn't enough. Being part of every human being isn't even enough. Yes, it is notable in the sense you describe, but that is a different sense of notability than the one described by WP:N. As an example, it has previously been discussed that places are not automatically notable. This came up when someone wrote a bot that started making pages based on census data or such. The verifiability wasn't enough, the accuracy wasn't enough. It didn't comply with the policy. See User:Uncle_G/On_notability#Notability_is_not_a_blanket for a better explanation.

Nor is being authoritative enough. Being reliable is one aspect of being notable, and being independent is another entirely.

Like I said, I think this is good content. I've suggested a change to the deletion policy that would stop deletion being a solution to non-notability. We mustn't just ignore the policy - we must change it.

-- BenBildstein 07:25, 16 August 2007 (UTC)

I'd like you to note that the Middle finger of the human hand has its own article. It's only notability is that it's a feature of the body. If you're going to start being a policy lawyer about all this stuff, then I'll direct you to the official policy WP:IAR which is "Ignore All Rules". If WP is better because of something, even if it breaks the rules, then it stays. As you stated yourself, this article should be here, it just doesn't meet the Notability requirements. If you believe that, then ignore the notability policy! I think a little bit of this may be a little bit of BenBildstein climbing a particular monument. --Puellanivis (talk) 23:12, 5 December 2007 (UTC)

I found the page to be extremely informative. I think "common sense" should prevail here, rather than the "letter of the law" regarding notability.CurtChristnsn 13:24, 7 September 2007 (UTC)

This information on this page is really useful! -- Jan Niggemann 18:29, 26 April 2008 (UTC) —Preceding unsigned comment added by 84.164.80.62 (talk)

Units

Moved here from comments placed in the article by an anonymous contributor, 64.203.165.227:

It'd be nice if the author of this page would add what units these values are in. Is it megabytes, kilobytes, etc...

My response: The display itself shows that the units are K (kilobytes). Is something more needed? Jeh (talk) 02:09, 30 January 2008 (UTC)

I think this page should have some discussion about whether the "commit charge peak" value is actually correct as shown when the windows task manager is open. For instance I have noticed that in all computers when extra RAM is added the peak values go up with the same programs running even though (for instance ) only half the available RAM is being used. —Preceding unsigned comment added by 114.78.137.238 (talk) 10:59, 25 November 2009 (UTC)

Fair use rationale for Image:Windows Task Manager Performance.png

Image:Windows Task Manager Performance.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 03:17, 12 February 2008 (UTC)

What is the origin of the phrase?

The article does not explain why a measure of virtual memory is called "commit charge." That is not obvious, at least not to me. Dratman (talk) 03:37, 10 August 2008 (UTC)

Really? I thought the term obviously derived from being the memory the OS is charged (entrusted) with that is committed (VM term meaning not backed by a file and not re-creatable). The English is a bit obscure, but in something like a column heading, concise is more important than everyday. 79.123.73.149 (talk) 23:03, 10 April 2012 (UTC)

Undefined terms

I found this article to be unclear. It does not explain what "backing store" is, nor what "pagefile-backed" means. In general, it seems to assume a fair amount of knowledge that is probably not common. I realize that a thorough discussion of computer memory and operating systems is not appropriate here, but some of these terms could be fleshed out a little bit, or linked to explanations elsewhere (though the virtual address space article has similar problems), without exploding the length of the article. Images of the Task Manager dialog box would also be helpful. Uunter (talk) 20:26, 6 February 2009 (UTC)

Amen. The article uses a bunch of jargon to explain a term which is jargon.

In my computer, I have RAM and I have a hard drive. I know that when the computer runs out of RAM, it starts using hard drive space. How about we start with those common terms (RAM and Hard Drive) and the common concept (running out of RAM starts to use the hard drive) as a starting point, and define all these jargon terms in relation to the two common terms and the common concept?

Since I first read this convolution over 10 years ago, Wikipedia has lost one-out-of-four stars because of this single incomprehensible article.

74.197.156.147 (talk) 21:08, 21 May 2015 (UTC)

Hm, well, actually, it uses hard drive space long before it runs out of RAM. (But that doesn't really have anything to do with "commit charge".) To completely explain all of this requires a complete description of how Windows implements virtual memory. This is a subject of a 200-page chapter in the Sixth Edition of Windows Internals. It isn't easy to pluck a concept like "commit charge" out of all that and explain it in a self-contained article. I'm not saying the article can't be or shouldn't be improved, but every time I've started to try it the result has just expanded beyond hope. I'm sure people will keep trying. Jeh (talk) 23:15, 21 May 2015 (UTC)

post a common rule how big the pagefile.sys should be

post a common rule how big or small the pagefile.sys should be. the articel should be a bit more practical--User1973 (talk) 17:40, 28 June 2009 (UTC)

Please see WP:NOT. In particular Wikipedia is not a how-to manual. Jeh (talk) 02:40, 29 June 2009 (UTC)

Some information outdated

The article does not reflect the version of Task manager included in Windows 7 which, for example, under Physical memory lists Total, Cached, Available and Free, while the article refers to Total, Limit and Peak. Silver hr (talk) 13:37, 27 January 2011 (UTC)

Win7 Task manager in the "Physical Memory" section in the Performance tab is not showing you "commit charge" at all, but rather physical memory (RAM). Commit charge is a category of virtual memory, not physical. Jeh (talk) 10:11, 4 April 2011 (UTC)

Definition provided does not match reality

In computing, commit charge is a term used in Microsoft Windows operating systems to describe the total amount of virtual address space for which the backing store is the pagefile. It may be thought of as the maximum potential pagefile usage.[1]

OK. But I have no pagefile. (XP) It was set to 0 in SysProps > Advanced > Performance > Advanced > Virtual Memory, because additional physical RAM far exceeded the system's needs. (Lots faster! -- and no, don't care for kernel dumps, etc.) And pagefile.sys disappeared from the root directory (hidden/sys view enabled). So, there is *no* pagefile backing store for anything.

Which leaves me (and a lot of other people, some fairly tech-savvy) still wondering what is meant by "commit charge". MS is about as much help as usual (i. e., zero.) It doesn't correspond to total VM size of all apps/processes when that column is enabled in Task Manager, nor can I get any set of numbers in TM to add up to anything close to the Commit Charge shown. Could anyone who actually *knows* please create a definition that is correct -- reproducible, calculable, etc., as well as sourced? While OR isn't enough to edit the article, I'd have nothing with which to replace it anyway. But the given definition fails miserably. Thanks. Unimaginative Username (talk) 05:50, 18 March 2011 (UTC)

I suppose that on such systems "for which the backing store would be the pagefile if you had one" would be descriptive. It's the same sort of allocation whether you have a pagefile or not: Pageable stuff for which no backing store other than the pagefile (like a mapped file) has been specified. Results from calls to VirtualAlloc and similar. Jeh (talk) 06:14, 18 March 2011 (UTC)

More: It's the sum of what PerfMon calls "Private Bytes" for every process - what task manager shows as "commit size" in Vista and 7 - plus some kernel-space pageable data (mostly the paged pool), which doesn't show in TM's process list (no, it's not the "system" process). That's why you can't add up anything under Processes to reach that total. But the principal contributor is indeed each process's "commit size". Jeh (talk) 06:23, 18 March 2011 (UTC)

Jeh, I took a look at your page, and if anyone could answer, you could. Appreciate your time. But we're still not getting a real answer. For one thing, the issue of "circular definition". But the principal contributor is indeed each process's "commit size".Each process's "commit size" -- what is the definition of "commit size", or "private bytes", and where is it shown for a given process or app?

(1)

I know the diff between the kernel allocations and "system process", at least as shown in TM. I added all the VM at a given point in time = ~ 219 MB. "Paged pool" = ~ 1.3 MB. Kernel Memory (Performance) = Total, 36,176; Paged = 23,692; Nonpaged = 12,484. Commit charge = 293 MB. Still not close.

(2)

From the article: The commit charge for each process does not include other major contributions to the process's virtual address space, such as mapped files. For this reason, the process's working set may be larger than its "VM size" (its contribution to "total commit charge"), and the total commit charge is not at all inclusive of the total memory (physical plus virtual) actually in use. ... Absolutely: in most cases, Mem Usage > VM. (One exception was anti-virus, which had a huge VM, for reasons I can understand.) ... So, we need to add in " mapped files" to get to the total Commit Charge? A quick look at that article referred once again to Virtual Memory, of which my systems have none.

(3)

Sorry to be so bothersome, but *someone*, *somewhere* -- maybe the person who invented Task Manager? -- knows exactly what this is, what it consists of, how it's computed, and, probably, how the raw data can be obtained (perhaps with 3rd-pary programs). The problem is, this is an encycylopedia, and the definition isn't at all encyclopedic. Thanks for your time, and any future time -- and to anyone else who can make this clear. Unimaginative Username (talk) 05:02, 19 March 2011 (UTC)

(1) Try it this way: "Commit size" or "private bytes" is pageable virtual address space for which no backing store has been specified other than the pagefile. Another way to put it is that if everything in RAM that's pageable had to be paged out, and you actually had a pagefile, that's how much pagefile space it would take up.

By the way, disabling your pagefile is a bad idea. And I don't care how much faster your system seems to be on some things - it is slower on other things, and the net result is a loss. The reason is that with no pagefile, ALL such data has to be kept in RAM all the time, regardless of how long ago it was referenced - at the cost of other things (like code and mapped data files) that are being accessed more recently. Part of the whole point of pageable virtual memory is that address space defined by a process but not referenced for a while can be paged out to make room for other stuff that's being used more often. You are overriding that mechanism for "private for no good reason.

Each process's contribution to the total "Commit charge" is what Task Manager in XP/2K3 calls "VM size." In Vista and 7 it's called "Commit size". In all versions Performance Monitor uses the term "Private bytes".

(2) Sorry but there is not to my knowledge a complete set of exposed "pieces" whose sizes add up to the whole of "commit charge." If that's what you're looking for you're going to be disappointed. The total of the per-process "VM size" (XP's task manager) plus the paged pool make up most of the commit charge... and that's as close as we can get to the total, to my knowledge.

By the way, that "PF Usage" thing in Task Manager? That's the commit charge too. It isn't the actual pagefile usage, it's the potential, worst-case pagefile usage - see my second definition under (1) above. Yep, even if you don't have a pagefile.

In any case, the whole concept of "commit charge" is really more about not running out of room for things than it is about accounting for what's taking up the room.

(3) No, memory mapped files do not contribute to commit charge. The virtual address spaces they define are backed by the mapped files, not by the pagefile. Memory mapped files do contribute to the total v.a.s. of each process that maps to them.

(3) "A quick look at that article referred once again to Virtual Memory, of which my systems have none." Of course they do; you can't run Windows without paging/virtual memory enabled, and you don't have to be using a pagefile to be using virtual memory. Take a look at your pagefault counts... Part of the problem here (most of the problem in fact) is that Microsoft has used the term "Virtual memory" in a couple of different ways. Reality is that "Virtual memory" is not just the pagefile.

Hope this helps. I'd suggest a good thorough reading of the memory management chapters in Windows Internals by Russinovich and Solomon if you really want to get into this stuff. I would also mention that a general interest encyclopedia really shouldn't be going into as much depth on topics this specialized as that book does. Jeh (talk) 10:13, 19 March 2011 (UTC)

JEH, thanks again for your time. I too have long felt that MS's multiple and confusing uses of "paging", "pagefile", "virtual memory", etc. have made such things hard to understand for reasonably well-read, but non-professional, users. "Kernel memory paged" -- no pagefile, but (found out) they mean "assigned an exclusive page in RAM". But somewhere else, "paged" means "paged to disk" -- etc. I'm not a *nix person at all, but in this sense, "swapfile" is more intuitive for stuff that is, uh, "swapped" back and forth from RAM to HD. (Not meaning to fork the discussion, just an example of MS' unclear terminology. Speaking of which, for the sake of simplicity, can we ignore the diff between MB/MIB, GB/GIB, etc., for the discussion at the end of my comments here?)

(1a) "Another way to put it is that if everything in RAM that's pageable had to be paged out, and you actually had a pagefile, that's how much pagefile space it would take up." OK, that makes sense. Thanks.

(2) "The total of the per-process "VM size" (XP's task manager) plus the paged pool make up most of the commit charge... and that's as close as we can get to the total, to my knowledge." OK. Any idea where the rest comes from? Is it an MS secret? (Not being facetious. They're known for a strange sense of what needs to be "proprietary".) ... Yes, the part about "PF usage" = "commit charge" was already in the article. Got that.

(3) Thanks. This made me aware that reading the article on VAS would be useful. Once again, MS confuses: "Virtual memory is easiest to comprehend if one thinks in terms of the VAS, and not the physical memory of the machine nor the size of its page file." [2] More multiple, conflicting uses of "virtual", in memory and otherwise. ... "you can't run Windows without paging/virtual memory enabled, and you don't have to be using a pagefile to be using virtual memory."... And *that* is what is so confusing about Windows terminology, at least to those without a M. S. in CSci. Yes, I need to read more tech info, as you suggested, to understand this. Like many professions -- medicine, law, etc. -- some IT people seem to use arcane jargon merely to try to keep out the illiterati, regardless of how literate (pun intended).

1. "Can't run w/o paging/virtual memory..." ... so, when HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management is set as follows: "DisablePagingExecutive" = 1 (PE off); NonPaged and Paged PoolQuota and PoolSize all = 0, as they are now, stuff is still being paged? -- in *this* case, I'm guessing they mean "assigned a specific block of RAM addresses (page) vs. random", as the Kernel Memory is still about 22 MB paged/12 MB nonpaged. (I know, read Russinovich...)

I agree that a general-interest encyclopedia shouldn't be a replacement for specialized professional literature, but only a basic overview, with references to the latter. It's just that the previous basic overview didn't seem to be quite accurate. I like your recent edits, and am glad to have provided some incentive to improve the article.

___________________

Now, slightly O/T to the article, but we're here anyway: (1b) "No pagefile = bad idea. Faster on some things, slower on others." Here are the numbers: (ignoring decimal/binary Δ): Original physical RAM = 512 MB. Default pagefile = 700 MB. Total physical plus pagefile (afraid to say "virtual" here!) = 1200 MB. Buy 1 GB RAM stick for the second slot. Now, total physical RAM = 1500 MB, which is greater than the previous total of physical+pagefile that MS and the OEM and the machine thought was sufficient. Hard to picture how that's a loss, having seen figures that it takes, like, 40,000 times as long for CPU to retrieve data that have been swapped from RAM to disk vs. data still in RAM.

The reason is that with no pagefile, ALL such data has to be kept in RAM all the time, regardless of how long ago it was referenced - at the cost of other things (like code and mapped data files) that are being accessed more recently.

The Commit Charge rarely goes very high into the 300 MB range, and has only a couple of times exceeded 400 MB. (Never GEQ 500, in years of use.) Given about 1350 MB "Commit Charge Limit" (I understand that the system reserves the remaining 150 or so for whatever), how is there "a cost of other things"? Can't they stay where they are, given all that room, while the "stuff that's being used more often" can choose from the remaining 1000+ MB of RAM? Or do I have to read Russinovich to understand that? (Is the word "bytes" missing from ""private for no good reason.", as in "private bytes"? The article says that "private bytes" are the VM column, currently totaling about 235 MB.) Why does the old stuff need to go to the manger (disk) if there's plenty of room at the inn (RAM)? (sorry - irresistible metaphor). So, *what* things/functions/etc. would be expected to be slower without the pagefile, or is that random?

In closing: I see the large number of page faults. I'm willing to experiment with trying a pagefile again. By default, about 1.5x RAM = 2.25 GB. That would more than triple my current total HDD usage of about 890 MB (that's another topic in itself, but trust me for now), and result in larger and slower full-disk-image backups, etc., but I'm game. But to be fair: I know that WP:NOT HOWTO, etc., but can you point me to a fair and full set of benchmarks I can run before and after the pagefile addition? I'd be happy to leave the results on your Talk, since it's OT here.

Anyway, thanks for your time, and I do think the article is improved for the people who actually need it -- i. e., the ones who don't already know this stuff. (In this writer's experience, the ability to explain a specialized field to reasonably-intelligent laypersons is quite uncommon, as the pro can't empathize with the eager and willing novice. Your humble servant has, at times, received kind words for being able to do exactly that in the fields in which YHS *is* an expert.) Cheers. Unimaginative Username (talk) 07:19, 20 March 2011 (UTC)

Addendum: Enabled system-determined pagefile, which proved to be 1470 MB, re-enabled Paging Executive, and rebooted. Some Page Fault numbers were a bit higher; some, lower; most, about the same. Overall, probably somewhat lower. But a quick look at Page fault indicates that they're not necessarily bad, or an error, and I got the impression that a page fault that stays in RAM (no pagefile) costs waaay less in overhead than a page fault that goes to disk. Commit Charge Limit went up accordingly, as did System Cache, but Kernel Memory kept about the same paged/unpaged numbers as above. And by closing all apps before backup, as usual, the pagefile must have been empty, because the full-disk-image backup wasn't any larger ... Haven't tried everything, but so far, don't notice any real change in speed, up or down. It's possible that on a system this optimized (with 99% free HDD space), and triple the OOB RAM, that it's as fast as it's going to get, pagefile or no. (Which is very fast, for a low-end machine with a $40 RAM upgrade.) Still curious to try independent benchmarks with and without pagefile, if possible. Unimaginative Username (talk) 12:05, 20 March 2011 (UTC)

Keep in mind that "Page Fault" includes soft page faults, which come from the standby list, as well as hard page faults, which come from disk due to paging I/O. Use XPERF or Resource Monitor in Windows 7 to get the number of hard faults. Modern Windows will not page out unless it absolutely has to, so there's no reason to imagine a performance benefit to deleting your page file. All you'll achieve is no longer getting crash dumps. [Alex Ionescu] --67.169.39.64 (talk) 14:11, 7 April 2012 (UTC)

Increasing Commit Limit

The article mentions that increasing the page file size is one way to increase the commit limit. There is another: on systems with Hot-Add Memory support, inserting additional DIMMs will also increase the commit limit, as the amount of physical RAM increases. [Alex Ionescu] --67.169.39.64 (talk) 14:13, 7 April 2012 (UTC)