Speichermanagement mit C

Florian Lohoff flo at rfc822.org
Sun Apr 28 18:34:03 CEST 2002


On Sun, Apr 28, 2002 at 06:22:36PM +0200, Andre Landwehr wrote:
> On Sun, Apr 28, 2002 at 06:19:14PM +0200, Dennis Wetzig wrote:
> > Weil Du mit free() den verwendeten Speicher nur für den gleichen Prozess
> > wieder verfügbar machst, ihn aber nicht "an das System" zurück gibst.
> > Der verwendete Speicher eines Prozesses kann somit nur wachsen, nicht
> > aber weniger werden. 
> 
> aha, so ist das also... und gibt es einen Weg, ihn an das System
> zurück zu geben?

Nein - Aus geschwindigkeitsgruenden - Wenn man sich den page fault
handler ansieht geht das so einfach nicht - Wofuer gibt es swap :)

Erster check

arch/i386/mm/fault.c:do_fault

    180         if (address >= TASK_SIZE && !(error_code & 5))
    181                 goto vmalloc_fault;

D.h. ist die addresse oberhalb der maximalen TASK groesse - Dann ist
es ein "vmalloc" fault - d.h. virtueller speicher innerhalb des kernels.

mm/mmap.c:find_vma

    644                 if (!(vma && vma->vm_end > addr && vma->vm_start <= addr)) {

Wenn vm_end > fault_addr und vm_start < fault_addr sind wir im gruenen 
bereich.

Wenn ich jetzt sparse memory zulasse d.h. ich kann loecher in meinen
mappings haben - dann muss ich aufwendig listen durchsuchen was extrem
aufwendig sein kann - Man bedenke eine typische CPU hat zwischen 32 und
64 TLB eintraegen und im normalfall muss ich alle 4K einen page fault
behandeln und die liste durchsuchen.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20020428/f6697385/attachment.sig>


More information about the Linux mailing list