Prev: Are PCs having TOO MUCH computing power?
Next: Need help with Seagate HD in HP Notebook
From: Paul on 3 Mar 2010 23:18
Grumps wrote:
> GT wrote:
>> "Grumps" <not(a)here.com> wrote in message
>> news:7v4q0hFk3tU1(a)mid.individual.net...
>>> I'm trying to work out 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.
>> Brian's answer covers all the points you need to know, but why you
>> want to know which bits of RAM are being used. Are you experiencing
>> problems or crashes - wondering if certain memory areas are failing?
>> Memtest will test out your RAM for you.
>
> I have a piece of hardware that does big DMA (>128MB), and needs this size
> of contiguous memory. When the driver is called to lock this block, it
> fails. I was just wondering if we could prove that this size of contig
> memory was present, then we could bash the driver author to correct his
> code.

I thought the idea was, drivers instantiate just as the desktop appears
on your PC screen. At that point in time, a driver could acquire whatever
memory it needs. (No programs would be loaded at that point in time.)

Normal addresses the OS uses, are based on virtual addressing. DMA hardware
works on physical addresses as a rule (at least the hardware I used to build
did). The driver needs to call some routine, which has the ability to guarantee
that a memory allocation is contiguous in the physical domain. A lot of other
software uses of memory, are quite happy to use virtual addresses for such
things. The processor has a TLB (and software page tables), to handle
translations from virtual addresses to physical ones. DMA circuits may or
may not have the services of something similar when they issue transfer
requests. It may it fact mean, that depending on the kind of PC the
hardware is plugged into, two different drivers or code paths are needed.

http://en.wikipedia.org/wiki/Virtual_address

http://en.wikipedia.org/wiki/Translation_lookaside_buffer

In this article, they describe something called an IOMMU. To me, such
a thing suggests the ability to use virtual address allocation with a
DMA device. As long as the IOMMU has similar entries to the TLB and
page tables, the hardware bits and pieces would all "be on the same
wavelength". The AMD processors have had an IOMMU around the time
that S754/S939 showed up. On Intel, it might be Core i7/i5 where
such a thing shows up (the most convenient time to implement it,
is the same time as you're putting memory interfaces directly on
the processor). If you have a Pentium 4 system, that is less likely
to support an IOMMU. (Maybe something like a server chipset had
something like that. On a desktop there would be less reason to
waste the time on it.)

http://en.wikipedia.org/wiki/Iommu

In any case, at the time the driver instantiates, there should be
an opportunity to get whatever memory is needed. Then, it becomes a
question of whether a chunk can be obtained, via PHYSADDR rather than
VIRTADDR. A series of virtual addresses, don't have to be physically
contiguous. You can grab two physically separated chunks of memory
and assign virtual address mapping that in the virtual space looks
contiguous. But that would break a DMA circuit which is only capable
of getting at things via their physical address.

If a person wished to debug something like this, it would likely
mean using a kernel debugger (rather than one in user space),
and finding and dumping the translations of the memory in question.

Paul
First  |  Prev  | 
Pages: 1 2
Prev: Are PCs having TOO MUCH computing power?
Next: Need help with Seagate HD in HP Notebook