> -----Original Message----- > From: kernelnewbies-bounce@xxxxxxxxxxxx > [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of Pharaoh . > Sent: 27 March 2007 08:58 AM > To: kernelnewbies@xxxxxxxxxxxx > Subject: vmalloc - page tables > > Hi > > I am confused about the way vmalloc works. AFAIK, only 128 MB > is available for vmalloc on x86 and this memory is only > virtually contiguous and not physically when allocated by a > process. When this memory is allocted then the processe's > page table does not contain the mappings, instead the > mappings are only stored in the init_mm->pgd i.e. the master > page table and when the vmalloced memory is allocated then > page fault occurs and the current processes page table is > modified according to the master page table. Is this correct? > The entire thing I am talking about? > I believe the page fault occurs when a memory access is attempted. But other than this, that's how I understand it. > If yes then, why it is done this way? I mean why only the > master page table is modified and then we have to wait for a > page fault to occur and then sync up the process's page > table, isnt this an overhead? For normal memory allocation > this is not applicable, right? > I remember correctly (I'm in the process of learning this myself) it reduces the overall overhead. There's a chance that a process will malloc a reasonable amount of memory that it will not use straight away, in fact it may never use some of it. By waiting until the page is actually being used this overhead can be broken down and pontentially saved. Is that right? Martyn ---- Martyn Welch Principal Software Engineer Radstone Digital Processing Part of GE Fanuc Embedded Systems Phone: +44 (0) 1327 322748 email: martyn.welch@xxxxxxxxxxxxxx web: www.radstone.com ________________________________________________________________________ This e-mail has been scanned for all viruses by Star.The service is powered by MessageLabs. ________________________________________________________________________ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
