Re: Doubt regarding memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2007-02-27 at 20:51 +0200, Tzahi Fadida wrote:
> On Tuesday 27 February 2007 18:12, Rajat Jain wrote:
> > On 2/26/07, Tzahi Fadida <Tzahi.ML2@xxxxxxxxx> wrote:
> > > From what i understand, this kernel mapping of addresses is a bit
> > > deceiving since all addresses generated from kmalloc, vmalloc, etc... are
> > > virtual. The difference is architecture dependant in that the MMU unit in
> > > the architecture knows to pass thru, instead of translation, addresses of
> > > certain ranges. In the case of x86 i believe this is the zone thing. I.e.
> > > if i understand correctly, if you have 512mb you can address physically
> > > (virtually direct :)) the dma and normal zones up to 512mb and then (i
> > > think), immediately after 512mb your translated virtual memory begins.
> > > However, there is an upper limit (for 32bits systems) and if you have 1gb
> > > of memory the normal zone ends at 896mb and the translated (not passed
> > > thru) region starts at 896mb.
> > >
> > > Is that correct?
> >
> > No, IMHO.
> >
> > All the addresses generated by the CPU (irrespective of the amount of
> > memory) are essentially virtual addresses, and thus need to pass
> > through the MMU to actually determine the corresponding physical
> > address.
> >
> > Now, in case of DMA or NORMAL Zone, the the virtual to physical
> > address mapping is an "identity mapping", meaning that they differ by
> > a simple offset (generally 0xC0000000).
> >
> > In case of HIGH memory zone, a mapping needs to be created.
> 
> I think that this is what i meant, i.e., pass thru = identity mapping.
> Anycase, what i am not sure about is where the not identity mapping 
> begins(i.e. virtual)? only at 896mb or if you only have 512mb ram (for 
> example), right after the 512mb? More over, does 512mb of physical ram 
> suggests there is no high memory in the computer?

   Well, im afraid you are getting it all wrong. What rajat said was,
identity mapping with an offset of 0xc0000000 most of the times , which
means eg.
  If you have your ram of 512mb physical address from 0x10000000 -
0x30000000, your kernel will map the same from linear address(virtual)
0xc0000000 - 0xf0000000. So, its 512mb of virtual space, mapped down to
512 mb of physical addresses here. So 
   0xc0000000 ---> 0x10000000
   0xd0000000 ---> 0x20000000 etc.
And yes, 512 mb of physical ram means there wont be a need for HIGH_MEM
on the comuter. Because it will only be used if you have physical memory
more that that of the range of ZONE_NORMAL i.e. 896mb.

> 
> Regarding 0xc0000000, in decimal it is something like 3,221,225,472 addresses 
> (i.e, i think it is 3gb). How does it relate to dma and normal zone i don't 
> understand. From ldd3, the dma zone is 0-16mb and normal is up till 896mb in 
> x86 which is far less than 1gb. Which, btw, i also does not understand this 
> number, why 3gb and not 1gb, the kernel works backwards? i.e. starts from 4gb 
> and the dma and normal space is from 4gb-3gb and the high mem is from 3gb-0?

  The ZONE_DMA is first 16mb of ram, because ISA (not sure aboout the
PCI though, experts please chip in) busses, could only address memory
using 24-bits, Since the DMA accepts physical addresses, and busses wont
recognize any greater that 2^24, the DMAable memory restricts down to
2^24 = 16mb. and thus ZONE_DMA.

   Again, kernel tries to map the whole of physical memory available in
an address range of 0xc0000000 - 0xffffffff. however, if its more than
896 mb, it has to use the last 128mb of virtual address space to map in
the extra physical memory in and out dynamically, and thts your
ZONE_HIGH_MEM.

   And no, the kernel doest work _backwards_ ;-) 

cheers,
sandeep




--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux