question on dup_task_struct

question on dup_task_struct

[Oliver Neukum]

Hi,

why is GFP_ATOMIC used in fork.c::dup_task_struct?

	TIA
		Oliver


	

Re: question on dup_task_struct

[Andrew Morton]

Oliver Neukum wrote:
> 
> Hi,
> 
> why is GFP_ATOMIC used in fork.c::dup_task_struct?

Presumably so that the allocation of the task structure can
dip into the emergency pools, giving fork a better chance
of succeeding?

We don't need to do that now - we can run page reclaim in
there as well as dip into the emergency pools.

 fork.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

--- 2.5.30/kernel/fork.c~fork-alloc	Sat Aug  3 15:19:10 2002
+++ 2.5.30-akpm/kernel/fork.c	Sat Aug  3 15:19:54 2002
@@ -106,9 +106,10 @@ static struct task_struct *dup_task_stru
 	struct thread_info *ti;
 
 	ti = alloc_thread_info();
-	if (!ti) return NULL;
+	if (!ti)
+		return NULL;
 
-	tsk = kmem_cache_alloc(task_struct_cachep,GFP_ATOMIC);
+	tsk = kmem_cache_alloc(task_struct_cachep, GFP_KERNEL|__GFP_HIGH);
 	if (!tsk) {
 		free_thread_info(ti);
 		return NULL;

.

Re: question on dup_task_struct

[Andrew Morton]

Andrew Morton wrote:
> 
> Oliver Neukum wrote:
> >
> > Hi,
> >
> > why is GFP_ATOMIC used in fork.c::dup_task_struct?
> 
> Presumably so that the allocation of the task structure can
> dip into the emergency pools, giving fork a better chance
> of succeeding?

Or maybe it's to _make_ it fail, so we don't loop forever in
a 1-order allocation?

Let's find out, and add a comment, fer crissake.

Re: question on dup_task_struct

[Andrew Morton]

Andrew Morton wrote:
> 
> Andrew Morton wrote:
> >
> > Oliver Neukum wrote:
> > >
> > > Hi,
> > >
> > > why is GFP_ATOMIC used in fork.c::dup_task_struct?
> >
> > Presumably so that the allocation of the task structure can
> > dip into the emergency pools, giving fork a better chance
> > of succeeding?
> 
> Or maybe it's to _make_ it fail, so we don't loop forever in
> a 1-order allocation?
> 

It's not a 1-order allocation.  I'll go back to sleep now.

Re: question on dup_task_struct

[Linus Torvalds]

On Sat, 3 Aug 2002, Andrew Morton wrote:
>
> It's not a 1-order allocation.  I'll go back to sleep now.

According to slabinfo, it's an order-2 allocation at least on SMP-x86,
which is kind of sad. The object size is 1664 bytes, and the slab code
decides that putting two of them per page is too wasteful, so it
apparently puts 9 of them on 4 pages instead.

That does explain why it wants to dip into the low resources, but since
the VM for the last year or so tries hard to avoid allocation errors for
up to order-3 allocations the only thing that GFP_HIGH would add is to get
better latency at the cost of potentially being really nasty on the MM
balancing.

So I think it should be just GFP_KERNEL.

		Linus

Re: question on dup_task_struct

[Rik van Riel]

On Sat, 3 Aug 2002, Linus Torvalds wrote:
> On Sat, 3 Aug 2002, Andrew Morton wrote:
> >
> > It's not a 1-order allocation.  I'll go back to sleep now.
>
> According to slabinfo, it's an order-2 allocation at least on SMP-x86,
> which is kind of sad. The object size is 1664 bytes, and the slab code
> decides that putting two of them per page is too wasteful, so it
> apparently puts 9 of them on 4 pages instead.

> So I think it should be just GFP_KERNEL.

Trying a little bit of active defragmentation for 4 and 8-page
allocations should be trivial with rmap.  If you want I could
take a stab at writing this code.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/