Hi,
why is GFP_ATOMIC used in fork.c::dup_task_struct?
TIA
Oliver
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;
.
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.
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.
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
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/