Re: put_task_struct and RCU

[GoatZilla <goatzilla@xxxxxxxxx>]

Thanks.

I actually followed it a bit further.  delete_put_task_struct actually does get called, it was just getting called later than I thought.

The task_struct still doesn't get free'd though.  When I look in proc/slabinfo, I see a large pile of task_structs remaining, and if I run enough processes (in serial fashion), literally I run out of memory.

The problem it seems is that when put_task_struct is called, task->usage == 2 (which is the initial value).  The decrement only gets it to 1, so the free is never actually called.

http://lxr.linux.no/linux+v2.6.26.6/include/linux/sched.h#L1474

Looking in fork.c, there is a comment on line 219:

http://lxr.linux.no/linux+v2.6.26.6/kernel/fork.c#L219

usage is initialized to two -- one for "us" and one for whoever calls release_task().  So the decrement that I'm seeing in put_task_struct is (probably) the second expected decrement, but I can't seem to find where the first decrement is supposed to occur...  Anybody happen to know?



Thanks again!

On Wed, Jun 17, 2009 at 12:02 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:

On 6/17/09, GoatZilla <goatzilla@xxxxxxxxx> wrote:
> Can someone explain what the normal path for freeing a task's task_struct
> resources after it's finished?  I'm working on a 2.6.26.6 kernel which
> doesn't seem to free these resources after a task is finished.
>
> Apparently, release_task() is called which at least sets up most of the
> work.  The actual freeing of the task is left to delayed_put_task_struct,
> which is registerd as an RCU callback.
>
> I set a breakpoint at delayed_put_task_struct, and it never gets hit.
>
> Where exactly is the callback is actually supposed to be invoked in the
> kernel.  Is it somewhere in or near the scheduler or switch code?

IMHO, after not being used, task_struct is just marked as "free" and
put it back to slab, as you can by typing:
$ cat /proc/slabinfo | grep task_struct

so, in other word, it's really only free-ed if there is high memory
pressure and forcing the kernel VM to release some of slab cache.

CMIIW people...

regards,

Mulyadi.