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 <[email protected] > wrote: > On 6/17/09, GoatZilla <[email protected]> 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. >
