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:
IMHO, after not being used, task_struct is just marked as "free" andOn 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?
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.
