Where has the comment thread on Page File stuff gone to?

Question

On What's wrong with disabling the Windows page file? Mehrdad and I had a non-heated discussion on page files, is it still available to us so that we continue on it in chat? I also might need it for reference in the near future when composing a blog post about it. Now, it has been removed without any reason while it could have been migrated to the chat instead, I also got no message on the removal either...

Answer 1

Tom Wijsman **Attention:** There is only a limited amount of memory given to drivers, called the [`non-paged` and `paged` pool](http://bit.ly/rttIee) memory sections. A page file is necessary for when the paged section gets full, as a gamer I have seen a game complain about paged pool memory just because I had my page file disabled on a 8 GB system. Conclusion: **Page files are necessary, they prevent paged pool depletion and actually [do speed up](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dont-throw-those-paging-files-away.html) your system.**
Mehrdad @TomWijsman: Could you mention exactly *which sentence* of that page you're referring to, which refer to **speedups** specifically?
Tom Wijsman Most of the page?
Mehrdad @TomWijsman: Nothing I see on the page mentions why there would be speedups on a system with, for example, 4 GiB of free RAM, out of 6 GiB -- I think I'm missing what you're referring to. Could you paste the relevant quote here?
Tom Wijsman "paging files have multiprogramming benefits", "Eliminating paging files puts greater eviction pressure on read-only code and data", "Eliminating paging files causes mostly-idle processes to deny resources to active processes.", "Paging files are used to avoid some of the problems with memory overcommitment."; as said, there is no relevant quote, it's most of the page.
Mehrdad @TomWijsman: Well, the problems I have with those quotes are as follows, respectively: quote #1 doesn't say anything; #2 doesn't say *why* this should be true in the case of ample free memory (it's an assertion with no reason), #3 just doesn't make sense (what resources? *what exactly* is being denied, and *why*?), #4 is vague and uses weasel words (what are "some of the problems"?). Really, I didn't find anything concrete in any part of the page -- it looks effectively like a page of hard-to-believe "facts" with no explanations whatsoever, though maybe I missed something?
Tom Wijsman #1 says exactly what it [says](https://secure.wikimedia.org/wikipedia/en/wiki/Multiprogramming), simultaneous page file and memory usage. #2 Ample free memory is irrelevant, trimming is done on a regular basis. #3 In the context of memory, that would be memory resources. Memory that is unnecessary clogs the Page Table, resulting in a system slowdown. It's denied from faster look-up of the memory, as well as larger resident sets. #4 is in the case of overcommitment, please note that in my first comment I gave a simple example of this that can apply even though you have 4 GB free.
Tom Wijsman Please note that the author has worked with drivers and has been a MVP. More details on the internal working, which are a necessity to have understood, can be found in the Windows Internals books as well as various online articles. Mark Russsinovich [has done some that push the limits of memory-related stuff](https://blogs.technet.com/themes/blogs/generic/postlist.aspx?WeblogApp=markrussinovich&GroupKeys=). Also, there is a [mass upvoted answer on ServerFault explaining the effect on memory allocations](http://serverfault.com/questions/23621).
Mehrdad @TomWijsman: Thanks for the reply, it has interesting info. Replies: #1 still doesn't say much (why is that a benefit, when memory is free?). #2: I don't understand why it should get trimmed, but let's say for the sake of argument that it does. How is paging in a paging file different from paging in the original file?  #3: I never thought of this, but now that you mention it: why would "clogging the page table" cause a system slowdown? If the TLB is fully associative, and if some pages are never used, how could they "clog" the TLB? #4 I'm not sure I still understand what it's referring to.
Mehrdad @TomWijsman: BTW, I haven't looked at the ServerFault page yet, I'll look at it as soon as I get the chance. It seems interesting!
Tom Wijsman #1 Memory is not a free operation and a look-up as well as allocation still consumes time, especially when this involves page table look-ups (this has nothing to do with the page file, not to be confused). You need an understanding of how memory and page table look-ups work to get this. #2 Because if you never trim the resident set then the only thing it does is grow in size. Note that only unmodified code can be paged to the original file, while anything else can only be paged to the page file. #3 Because allocations take longer, see last link I shared. #4 Very first link I shared.
Tom Wijsman I don't know your knowledge on the internals of Memory or Windows, but it would be much nicer if I could explain this by writing out a blog post. Unfortunately I don't have the time for it now due to school tasks and projects, but might consider into writing one in the future. I've learned it the hard way by discovering that my paged driver pool memory got full, and I don't mind having some GB on my disk for the page file given the low cost these days. In terms of space it makes sense not to have a page file, but in terms of performance and stability I'd rather have one these days...
Tom Wijsman Also, please note: While the TLB is fully associative, it is only a cache of recently used mappings from the operating system's page table. (Source: [Wikipedia - Page Table - The translation Process](https://secure.wikimedia.org/wikipedia/en/wiki/Page_table#The_translation_process))
Mehrdad @TomWijsman: #1: I *am* aware of how the page tables, TLBs, etc. work, but I *still* don't understand how the page file affects anything here. Oh well. :(  #2: Yes, but why trim it if it's never going to go beyond 20% of your memory anyway? Shouldn't you trim only when necessary? #3: **Two** issues with this: (a) Couldn't they duplicate data in RAM instead?, and (b) The post's argument seems to rely on *"Imagine a simple scenario where some app ... demands 80% of existing RAM."* which, on my system, quite literally doesn't even get *close* to happening any more than once every few months.
Mehrdad @TomWijsman: Yeah, I'm busy in school too, no worries. :) And yes, that's my entire point: since the TLB is a ***cache*** of the ***recently*** used mappings, then how does an "idling" (i.e. non-executing) process "clog" it? By definition, it hasn't run recently, right? (As for #4: I'll take a bit more look at it, but the question that pops up in my mind is, why the OS can't use the RAM for more paged pool? Is it more difficult than using the page file or something?)
Tom Wijsman #1 The system can perform a read/write from/to the page file while it does other memory operations. #2 Because that's how it works. It's better to trim preventive and have no delay than suddenly doing big trims that introduce a delay, which would interrupt a possible time-critical task/process. #3 (a) This would have impact on the TLB, you don't want it to cache PTEs for duplicate data. (b) Read the paragraphs about memory allocations before that, that paragraph your refer to is about disk trashing which has nothing to do with the paragraphs before that.
Tom Wijsman It's when you switch between stuff that you also want things to go quick, try switching between some programs, visiting the start menu, going through Windows Explorer, checking your notification area and those kinds of things. Note that there's also a bunch of services running that do nothing at all in the background, and who knows what else. Surely your TLB cache won't suffice, so look-ups to your memory are made (and things like [de]allocations). This switching (and replacing parts of your TLB cache) goes faster when the services that do nothing at all are paged away to the page file...
Tom Wijsman Please note that I said clogging the page table, not clogging the TLB cache. As for #4: As far as I understood it both the non-paged and paged pools are given a static size on boot that suffices most use cases, as a gamer the paged pool can easily fill and if there is no page file it will get full otherwise it just pages data out of it. Not really relevant to this discussion is that the non-paged pool can't be paged away at all (as it's necessary for the kernel), but in normal occasions it should never hit it's limit.
Mehrdad @TomWijsman: #1: Can't it perform do the same thing with RAM? #2: I *guess* that makes sense? But I feel like it could be optimized to a hard-coded value, say 50%, before which it wouldn't trim anything at all. Oh well. #3: (a) Hmmm... I would need to convince myself that the impact on the TLB would actually be significant, but that seems quite reasonable of a possibility, thanks. :)
Mehrdad (b) Ah, okay. But I don't quite understand what you mean: `This switching goes faster when the [idle] services are paged away to the page file`: why are you assuming that the service *must* be accessed if it's tucked away in memory somewhere? Can't it be ignored just the same as if it were on disk? (Also, I don't understand how "the page table" can be "clogged". Isn't it process-specific? And isn't it a random-access table in a 2- or 3-level hierarchy? What gets "clogged"?) #4: Well, if the paged pool can get extended into a page file, it should be able to be extended into RAM too, right?
Tom Wijsman #1 Would require a change in the way the TLB functions, it has to know which is duplicate and which is not. #2 Depends on the use case, but it's been optimized to fit the most use cases. Perhaps it can be changed but I wouldn't know how. #3 (b) I'm not assuming that it needs to be accessed, but the PTEs of the service just take up space in the Page Table which causes longer look-ups. In a random-access hash table, an individual deepest level index points to a linked list. This usually contains one PTE but when it gets clogged linked lists will contain multiple PTEs...
Tom Wijsman Apparently it's intended to be of a static size, I'm not entirely sure why but I guess it would make things more simple in the kernel. Perhaps Windows Internals or Mark's article I linked goes into detail on it, but it can get depleted when not using a page file.
Tom Wijsman **Attention:** There is only a limited amount of memory given to drivers, called the [`non-paged` and `paged` pool](http://bit.ly/rttIee) memory sections. A page file is necessary for when the paged section gets full, as a gamer I have seen a game complain about paged pool memory just because I had my page file disabled on a 8 GB system. Conclusion: **Page files are necessary, they prevent paged pool depletion and actually [do speed up](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dont-throw-those-paging-files-away.html) your system.**

Answer 2

It triggered a moderator flag and the comments were deleted by a moderator. Briefly reading through the history of the conversation, the whole conversation should have been in chat from the beginning.

Considering the question was posted in May, and the tone of the comments, it should have been deleted sooner. Feel free to contact the OP directly to continue that conversation, but please keep it off Super User and preferably off chat.