Re: MM deadlock [was: Re: arca-vm-8...]

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Wed, 27 Jan 1999 12:35:29 +0100 (CET)

> > Something like
> >
> > Chop memory into 4Mb sized chunks that hold the perfectly normal and
> > existing pages and buddy memory allocator. Set a flag on 25-33% of them
> > to a max of say 10 and for <12Mb boxes simply say "tough".
>
> this is conceptually 'boot-time allocation of big buffers' by splitting
> all available memory into two pieces:
>
> size_kernel: generic memory
> size_user: only swappable
>
> (size_kernel+size_user = ca. size_allmemory)
>
> This still doesnt solve the 'what if we need more big buffers than
> size_user' and 'what if we need kernel memory more than size_kernel'
> questions, and both are valid.

It does not have to look like that.
I guess we need some size_user memory on some ports anyway (i386 above 1GB
physical, sun4d above 2GB physical, sparc64 memory hotplug mem_map), but the
rest should be general memory.
I bet forcing every single driver in the kernel which ever does some kmalloc
to write hooks for relocating that buffer is utopic - it would add too much
complexity everywhere. You often don't keep track where all you put pointers
to the kmalloced area. So we'll have to live with some unmovable objects.
But for the rest, the memory allocator can behave like this:
either have some chunks in which non-swappable memory is being allocated, or
have some rule, e.g. that non-swappable memory grows from the lowest
physical pages up.
Now, for a swappable get_free_pages you can allocate it from anywhere, but
it would be good to give precedence to the memory outside of the current
non-swappable region(s).
For non-swappable get_free_pages, you first try hard to allocate it from the
current non-swappable region(s) (first looking if there are free pages, then
look if there are swappable pages (and in the latter case either swap them
off, or just move them to swappable regions)). If all non-swappable
region(s) are full of non-swappable allocations, then you allocate another
non-swappable region and swap-off/move some pages from there.
As long as we keep most of the objects swappable/movable, this will work
well. If there are too many unmovable objects, it will lead to deadly
fragmentation and this won't work.
But most of the objects are swappable/movable: everything referenced
in user pages only, vmalloc regions, or can be easily flushed.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.0 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/