Option to disable pagefile?
#1
Posted 01 November 2007 - 11:41 AM
Many thanks in advance.
#2
Posted 01 November 2007 - 12:23 PM
1. it's not recommended regardless of the amount of ram. Maybe size change would be a better fit.
2. Windows restarts the size during the setup, so it would require hacking. Not worth it.
#4
Posted 02 November 2007 - 02:39 AM
#5
Posted 02 November 2007 - 03:04 AM
Many thanks for the quick reply and writing this wonderful program.
1. I use nlite to create a XP setup CD for installing onto a USB HDD. Leaving the pagefile enabled may result in unpredictable behavior during the installation/boot up process and corrupting the host system as well. That is why it is recommended to disable the pagefile for USB installation.
2. Windows disables the pagefile by blanking the following key in the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"PagingFiles"=
Can the HIVESYS.INF file be modified in someways to achieve the same result?
Many thanks for your kind assistance.
Best regards.
#6
Posted 02 November 2007 - 02:57 PM
Even if I forced it again on the first logon it would still be created once until the next reboot.
#7
Posted 05 November 2007 - 09:04 AM
You are right about windows resetting the pagefile. Adding the pagingfiles registry key to hivesys.inf did not work. Even though the key was set to blank in system.sav, windows set it to C:\pagefile.sys in the HKLM\System\CurrentControlSet on first boot.
Also tried adding the key to setupreg.hiv, without modifying the hivesys.inf. Again no success. But this time the pagingfiles key in system.sav was not blank. So there is a difference on how the files setupreg.hiv and hivesys.inf are used during the windows setup process. Could you kindly explain?
So is there a way to prevent windows from writing the pagefile during the setup/boot up process?
If this is not possible, what needs to be done to disable it after the first boot?
Thank you for your patience.
#8
Posted 05 November 2007 - 10:48 AM
I would do it if there were a lots of votes for it. Generally it's not recommended.
#11
Posted 30 November 2007 - 04:38 PM
#12
Posted 30 November 2007 - 05:27 PM
just search the binary pagefile string in the dll and null it, done.
#13
Posted 11 January 2008 - 05:12 AM
If you dont remove the pagefile you get increased disk writes which are very bad for the life of the SSD..
Even the manual instructs you to remove it and a LOT of EeePC owners are using nlite (with XP or 2000).. the option would be very useful to all of them I think.
#14
Posted 13 January 2008 - 09:00 AM
Besides.. why is a Pagefile needed with 2gb of Ram or more?
#16
Posted 18 March 2008 - 11:12 PM
Cheers,
James
x
#17
Posted 21 March 2008 - 12:34 AM
This post has been edited by Muppet Hunter: 21 March 2008 - 03:11 AM
#19
Posted 21 March 2008 - 02:38 AM
The kernel will 'page' .dll and .exe code to 'backing store'. The kernel virtual memory manager will ALWAYS use backing store. If there is no page file, then real memory is used. There is no way to change this, no mystery reg hack, nothing.
As real memory fills up (commit charge), the kernel will actually start to unload more and more .dll and .exe code to make room for newly required pages. But you don't get all of the memory back. 'Stubs' are left in real memory so that the VMM can go back and actually find the needed .dll and .exe code.
As memory usage approaches the commit charge limits, a runaway condition can occur where the kernel is sucking up a significant percentage of CPU time unloading .dll and .exe and then reloading them from disk as program and user demands are made. One thing a paging file provides in this case is a structured and VMM-controlled place to retreive .dll and .exe code from. Much faster than going through the usual code loading process.
Another condition that will occur is memory fragmentation. All of the load/unload/stub activity chops real memory up pretty badly. You might think no big deal, but with an Intel system (no hardware memory management) the VMM code (and thus the CPU) has to manage all of the fragmented memory addresses to find spaces big enough to reload code. This is another unnecessary waste of CPU cycles. By the way, it's the use of dedicated hardware memory management that has given AMD a performance lead in the x86 space. Intels gain on the AMD perfomance numbers are mostly from raw CPU clock speed and efficiencies. However, Intel has seen the light on MMUs. The next generation of Intel CPUs will have an on-board MMU and use a Hyperchannel-like data pipeline to connect things up. But we digress.
NT/XP/Vista/Server200x kernels really need paging file to be at least 1:1 with real memory. You might not like the behavor of the kernel virtual memory manager, but it is what it is.
It's the technical details of how the VMM works along with a (minor) financial consideration why small machines like the Eee come with Linux and not XP. Just to accomodate a discounted OEM license of say, $25- would require the addition of a $50- hard drive which in turn would significantly reduce battery run time and increase boot time.
The people who design these new-gen small 'laptops' really do know what they are doing.
This post has been edited by newsposter: 21 March 2008 - 08:01 AM
#20
Posted 20 May 2008 - 12:44 PM
newsposter, on Mar 21 2008, 02:38 AM, said:
Has anyone maybe considered loading a RAM drive and using that as the swap space? I admit up front i'm WELL out of my comfort zone when talking about the internals of why OS's need swap space on a disk.



Help

Back to top









