Forcing NT to use RAM for PAGEFILE.SYS using RAMDISK ?? - Windows NT

This is a discussion on Forcing NT to use RAM for PAGEFILE.SYS using RAMDISK ?? - Windows NT ; The above was the subject of a pretty long thread in this group, back in 1997. http://groups.google.com/group/comp....784761a66f1d69 Sad to see that today with WindowsXP the situation hasn't improved. I have 2GB of RAM in my laptop, and TaskInfo shows that ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Forcing NT to use RAM for PAGEFILE.SYS using RAMDISK ??

  1. Forcing NT to use RAM for PAGEFILE.SYS using RAMDISK ??

    The above was the subject of a pretty long thread in this group, back
    in 1997.
    http://groups.google.com/group/comp....784761a66f1d69
    Sad to see that today with WindowsXP the situation hasn't improved.

    I have 2GB of RAM in my laptop, and TaskInfo shows that 1.4GB is free,
    but I still see periodic page-out activity on my disk, with only 130MB
    being used by the filesystem cache. I've enabled LargeSystemCache and
    various other registry tweaks to tell Windows to cache as much as
    possible, but it's still ineffective.

    It's interesting to note that running a natively compiled gcc under
    MSYS, it takes about 11 minutes to compile a large source tree on
    Windows. But, if I load up VMware under Windows with raw disk access
    and then boot Linux in the VM, I can compile the same source tree on
    the same drive in only 3 minutes, and the disk doesn't spin madly the
    whole time. Talk about pathetic.

    Moreover, if I then do a "make clean" on the Linux system and rerun the
    build, the entire build completes with just about zero disk activity.
    If I do the same thing on Windows, the disk spins busily both during
    the delete phase and again during the compile. Even if I preload all of
    the source tree into the cache (e.g., "find . -type f | xargs cat") it
    still wants to page things in during the compilation.

    It's idiocy like this that leads to people trying "dumb" ideas like the
    Subject line above. And even more ridiculous is that dumb ideas like
    that actually work to improve system response.

    Despite the fact that the SysInternals guys dropped access to those
    cache manager variables like CcFirstDelay and such in their current
    CACHESET utility, I decided to try to play with them on my current XP
    machine. I downloaded the Windows symbol files and fired up WinDbg, and
    found that the same variable names still exist, although their values
    are negative 64-bit integers now (system time, units of
    100nanoseconds). The units weren't surprising, but I don't understand
    why they're negative integers. Anyway, I bumped the delays
    (CcFirstDelay, CcIdleDelay, CcTargetCleanDelay) up to 30 seconds each,
    and I've noticed somewhat less paging activity going on. But it still
    keeps the drive busy during a big compile, and TaskInfo shows that the
    file cache shrinks and grows during the build, when I would expect it
    to continually grow. I guess part of the problem is that the cache
    manager always flushes pages whenever a file is closed, regardless of
    any delay settings. But I don't see why it *releases* those pages,
    especially since the files will be used again very shortly. (E.g., you
    compile a file, create a .o - that gets read again for moving into an
    object library, or it gets read again for linking into an executable.
    There's no reason to page the .o file out of memory so immediately, as
    Windows appears to do.)

    I'm thinking that the best approach to fix this stupid cache behavior
    that releases cache pages too early, is to write a filesystem filter
    driver that intercepts all Open requests and creates an additional
    reference to every file, the first time that file is opened. Then, it
    should not release this additional reference until several minutes
    after the file is closed, unless the file is explicitly deleted.

    All those explanations in the above-referenced thread about why Windows
    leaves so much RAM unused for multitasking purposes are pure bunk, by
    the way. Since Windows loads programs by demand-paging, it really only
    needs to leave a small amount of memory free - enough to build a couple
    process contexts, nothing more. There is no reason Windows should be
    letting 1.4GB of RAM go unused on this machine, paging stuff out
    continuously when there is no memory pressure on the system. An
    intelligent kernel design only pages stuff out because there is
    pressure to bring other pages in, otherwise it runs steady-state with
    no I/O. All Windows accomplishes with its current design is to consume
    battery power on a laptop, prevent the hard drive from spinning down
    and stay down, add wear and tear on the drive motors, etc. etc. etc...
    In short, it's designed to make your current computer fail sooner and
    force you to buy a new one ASAP.


  2. Re: Forcing NT to use RAM for PAGEFILE.SYS using RAMDISK ??

    ...it certainly accomplishes that. Another one this probably
    accomplishes is have your data recorded and on-disk after recovering
    from power failure, something that couldn't possibly be achieved with
    data kept in volatile ram.


+ Reply to Thread