Re: [PATCH] fork() failing

From: Marcelo Tosatti (marcelo@conectiva.com.br)
Date: Thu Oct 18 2001 - 13:16:06 EST


On Thu, 18 Oct 2001, David S. Miller wrote:

> From: Marcelo Tosatti <marcelo@conectiva.com.br>
> Date: Thu, 18 Oct 2001 15:04:15 -0200 (BRST)
>
> As you know, we currently allow 1-order allocations to fail easily.
>
> However, there is one special case of 1-order allocations which cannot
> fail: fork.
>
> Here is the tested patch against pre4.
>
> There are also some platforms using 1-order allocations
> for page tables as well.
>
> But I don't know if I agree with this special casing.
> Why not just put something into the GFP flag bits
> which distinguishes between high order allocations which
> are "critical" and others which are "don't try too hard".

Look at the comment on my patch. I've suggested that :)

I've added a __GFP_FAIL flag back in 2.4-ac something days exactly for
that purpose. I've ported the same code to the XFS tree so they could try
to "lazily" allocate (big) structures to build page clusters.

However, there is one nasty problem with it: How we can define "don't try
too hard" ?

Lets say you want to use the __GFP_FAIL flag when trying to allocate data
to do more readahead. If it fails too easily, we're never going to do
enough readahead.

What I'm trying to say is that we would need levels of "don't try too
hard" to have a nice scheme, and thats not simple.

See my point?

> BTW, such a scheme could be useful for page cache pre-fetching.

It could be used in a _LOT_ of performance critical parts of the kernel,
indeed.

> If you use a high order allocation, it is more likely that all
> of the pages in that prefetch will fit into the same kernel TLB
> mapping. We could use a GFP_NONCRITICAL for something like this.

-
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/



This archive was generated by hypermail 2b29 : Tue Oct 23 2001 - 21:00:21 EST