![]() | |||||||||||||
Messages in this thread |
Oleg Nesterov <oleg@tv-sign.ru> writes: > I think I have a really good idea. > > Forget about task ref for a moment. I thinks we can greatly > simplify the pids management. We don't PIDTYPE_MAX hash tables, > we need only one. I like it. If we run top we wind of with the same number of dynamic allocations, with task_refs (because /proc uses them). The amount of memory utilized is lower. Probes for unused sessions and process groups are a little more expensive but not noticeably so. Unless we can implement do_each_task_pid/while_each_task_pid in terms of for_each_task_pid. I am nervous about making the conversion. During fork is a very nice time to allocate these as it allows the rest of the code to assume they are always available. I think we had something similar several years ago, that's where the name struct pid came from. But it used a separate head for each type of pid, and it used a separate structure for what we now embed in struct task. It completely breaks my patch for multiple pid spaces. Oh well it isn't merged anyway. :) > And noe we can inplement pid_ref almost for free, just add ->count > to 'struct pid_head'. > > What do you think? I will take a good hard look at it once I send off my patchs to shore up task_refs in the -mm tree. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-06 22:22 [W:0.440 / U:0.060 seconds] ©2003-2008 Jasper Spaans | |||||||||||||