Re: Lock memory ?
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 02/20/04
- Next message: Joseph M. Newcomer: "Re: Displaying Multiple Text Lines At Runtime"
- Previous message: Doug Harrison [MVP]: "Re: clarification"
- In reply to: Doug G: "Re: Lock memory ?"
- Next in thread: Erik: "Re: Lock memory ?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 19 Feb 2004 21:11:17 -0500
NT has always understood the difference between paging and swapping, and has always been a
paging kernel. No vestige of swapping has ever existed. However, the working set model is
a known way to optimize paging performance. VirtualLock gives the programmer a way to tune
that performance. My guess is that anyone who uses it will reduce the performance of both
the system and their program.
joe
On Thu, 19 Feb 2004 13:43:33 -0500, "Doug G" <nospam@frcnospam.com> wrote:
>(c) Good call. I suspect that VirtualLock might lock pages into the
>process's working set, but of course that doesn't keep the working set
>itself from being swapped out. The author of that documentation might have
>missed the distinction between paging and swapping, assuming that the NT
>kernel makes that distinction (which it probably does, or at least did at
>one time, having been based on VMS).
>
> Doug G
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
>news:ecs8301989132n84h0ic3n6l1t3c99r5tt@4ax.com...
>> Yes. But you won't like the answer, and you almost certainly don't want to
>do it.
>>
>> (a) There is far less memory than hard disk space. Disk space is cheap and
>these days it
>> can be thought of as nearly unlimited. Memory is expensive and extremely
>limited.
>>
>> (b) Locking a big buffer in memory will screw up your entire system
>performance.
>>
>> (c) If anyone tells you VirtualLock will work, they are wrong. The
>documentation lies.
>>
>> (d) You can write a device driver that does it. You do not want to write a
>device driver.
>> There is an example of a Windows NT 4.0 driver that does this in our book
>(Dekker &
>> Newcomer, Writing WIndows NT Device Drivers) but it is a legacy driver.
>You will need to
>> write a plug-and-play power-managed driver, otherwise using the driver
>disables all power
>> management on the motherboard. PnP/PM drivers are tedious to write. Very
>tedious. You can
>> find prototypes on the DDK source tree, but this is not a topic you want
>to tackle unless
>> you really understand what you are doing.
>>
>> So what problem do you think this approach is going to solve? Saving disk
>space? If so,
>> you would be wasting your time. Improving performance? Maybe, for one
>program, up to the
>> point where you have consumed all the permissible kernel memory. Of
>course, everything
>> else goes to pieces in terms of performance, including the file system,
>but your one
>> program would run a little bit faster.
>>
>> Until you tell us what the problem is, asking us how to implement a
>solution to an
>> undefined problem is not really productive. I would say with a fair degree
>of confidence
>> that whatever the problem is, locking pages into physical memory is almost
>certainly the
>> wrong solution (I know of two instances where it makes sense, but I'll let
>you define the
>> problem space. It is almost certainly neither of the highly-esoteric
>instances I know of).
>> joe
>>
>> On Wed, 18 Feb 2004 19:15:47 +0100, "Erik" <saruman@pandora.be> wrote:
>>
>> >Is it possible to allocate a buffer in physical memory,
>> >or lock the allocated memory, so, that it won't use hard disk space ?
>> >
>> >thx
>> >
>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: Joseph M. Newcomer: "Re: Displaying Multiple Text Lines At Runtime"
- Previous message: Doug Harrison [MVP]: "Re: clarification"
- In reply to: Doug G: "Re: Lock memory ?"
- Next in thread: Erik: "Re: Lock memory ?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|