Re: the new VM

From: Andrea Arcangeli (andrea@suse.de)
Date: Tue Sep 26 2000 - 15:16:26 EST


On Tue, Sep 26, 2000 at 09:10:16PM +0200, Pavel Machek wrote:
> Hi!
> > > i talked about GFP_KERNEL, not GFP_USER. Even in the case of GFP_USER i
> >
> > My bad, you're right I was talking about GFP_USER indeed.
> >
> > But even GFP_KERNEL allocations like the init of a module or any other thing
> > that is static sized during production just checking the retval
> > looks be ok.
>
> Okay, I'm user on small machine and I'm doing stupid thing: I've got
> 6MB ram, and I keep inserting modules. I insert module_1mb.o. Then I
> insert module_1mb.o. Repeat. How does it end? I think that
> kmalloc(GFP_KERNEL) *has* to return NULL at some point.

I agree and that's what I said since the first place. GFP_KERNEL must return
null when the system is truly out of memory or the kernel will deadlock at that
time. In the sentence you quoted I meant that both GFP_USER and most GFP_KERNEL
could only keep to check the retval even in the long term to be correct
(checking for NULL, that in turn means GFP_KERNEL _will_ return NULL
eventually).

There's no need of special resource accounting for many static sized data
structure in kernel (this accounting is necessary only for some of the dynamic
things that grows and shrink during production and that can't be reclaimed
synchronously when memory goes low by blocking in the allocator, like
pagetables skbs on gbit ethernet and other things).

Not sure if at the end we'll need to account also the static parts to
get the dynamic part right.

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



This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:18 EST