I'm trying to work out (that's the tenuous DIY link) what parts of my Windows PC's memory are free. You know when you do computer_management->disk_defragmenter->analyze, you get a graphical representation of where your files are on your HD. Is there anything similar for the memory? So I can see what's put where.
I don't think so. But you can see what processes are using memory and how much by going to Task Manger, via CTRL-ALT_Delete, and looking under the tabs for "Processes" and "Performance".
No. And even if there were, you can't do anything about it, nor does it matter.
Read this as to why;
piece of hardware that needs DMA to a contiguous area of memory. The associated driver (not ours) doesn't want to allocate this memory if it is too big, but still smaller than what task manager says is available.
I suspect that the most likely place to find the sort of software you are looking for would be as part of the sysinternals suite, assuming that you want to do this under Windows. Alternatively look for BIOS documentation. But I would have thought that the first port of call would have been the authors of the driver software.
It's not a good idea to rely on anything you find out about memory allocation. It is extremely, like by the milli-second, dynamic, and changes as processes are swapped in and out.
The best you can do is to take a snapshot (I don't know what tool you'd use with Windows today though) and analyse that. We used to call them 'Core Dumps', but that was when men were men, and programmers didn't eat quiche.
One is curious why you need to know? And what Huge said.
R.
not really, since it gets put wherever malloc() (or its equivalent can find a spare byte..
And changes constantly.
time to dump windows, or the hardware, since it appears that the total crapitude of both is now resulting in zero functionality.
One of the improvements in moving to the NT family was to prevent application software from writing to the hardware. Linus also does that.
I'd like to know what is the max contiguous memory chunk, as the driver we have will not play ball if we ask for 128MB. I just wondered if we could bash the driver designer armed with evidence that the PC does have that size available.
The call should succeed whether there is 128Mb of contiguous memory or not. Windows should just swap until it has recovered enough space. Whether the space is contiguous and where it is in memory isn't the sort of information that the OS should disclose to an application.
Do you mean physical memory? If so, it's broken. If not, it doesn't matter.
I've never written a device driver for Windows (*), but even I doubt that it is required for device drivers to access physical memory. Surely those days are gone?
I suspect this is nothing to do with memory fragmentation and everything to do with a bug; either in Windows, the device driver or task manager.
(* And yes, the implication that I have written device drivers for other systems is correct.)
Well, if I could see what the mem frag was like, then I could pin the problem down a bit more.
It has to be contiguous for the hardware to work properly. It can't do scatter gather DMA etc. The driver does return a pointer to a contiguous area if the requested size is much smaller than what we need.
In Control Panel->System->Device Manager you can view resources by type and choose memory. There amongst all the other _hardware_ addreses listed your driver should be informing windows of the memory range it has negotiated and reserved for DMA for the card, and unless you have access to the source code of the driver and can hack around with it (remembering that you would also be hacking around with whatever external process hardware is writing to the memory via DMA) it would be unlikely you can increase it.
Well unless your DMA device is sitting on the CPU side of the MMU it has to use physical memory as that is all that exists outside the CPU/MMU these days. I don't actually recall much that used DMA on the virtual side of the MMU.
There is a lot of information on the M$ site. This may be what you want
A device on the bus is probably going to require a physical address. Few systems do virtual-to-real mapping for I/O transfers. It means having to let the peripheral controller know of any changes to page tables, segment tables, etc. This is assuming DMA, of course. I did come across a mainframe that did it, but it's relatively rare.
The solution to not having contiguous physical memory is to page/swap until enough memory is obtained. Or to use a peripheral controller that will do scatter/gather.
Unless, of course, the DMA device is intelligent enough, when told the physical addresses of the page tables, to do its own virtual to real mapping on the fly.
IIRC the way memory gets allocated was tweaked a few years ago to try to minimise the risk of buffer overflow exploits - in order to do this, the memory has to be randomly allocated, or the exploit would simply lock enough to allow the hack to work, then trigger the code.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.