Most of the traditional unices maintained a pool for each subsystem
(this is really useful when u have the memory to spare), so not matter
what they use memory only from their pool (and if needed peek outside),
but nobody else used the memory from the pool.

I have seen cases where, I have run out of physical memory on my system,
so I try to log in using the serial console, but since the serial driver
does get_free_page (this most likely fails) and the driver complains back.
So, I had suggested a while back that important subsystems should maintain
their own pool (it will take a new thread to discuss the right size of
each pool).

Why can't Linux follow the same approach? especially on systems with a lot
of memory.


Balbir

Marcelo Tosatti wrote:

>Hi, 
>
>I've been testing pre6 (actually its pre5 a patch which Linus sent me
>named "prewith 16GB of RAM (thanks to OSDLabs for that), and I've found
>out some problems. First of all, we need to throttle normal allocators
>more often and/or update the low memory limits for normal allocators to a
>saner value. I already said I think allowing everybody to eat up to
>"freepages.min" is too low for a default.
>
>I've got atomic memory failures with _22GB_ of swap free (32GB total):
>
> eth0: can't fill rx buffer (force 0)!
>
>Another issue is the damn fork() special case. Its failing in practice:
>
>bash: fork: Cannot allocate memory
>
>Also with _LOTS_ of swap free. (gigs of them)
>
>Linus, we can introduce a "__GFP_FAIL" flag to be used by _everyone_ which
>wants to do higher order allocations as an optimization (eg allocate big
>scatter-gather tables or whatever). Or do you prefer to make the fork()
>allocation a separate case ?
>
>I'll take a closer look at the code now and make the throttling/limits to
>what I think is saner for a default.
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>