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