Messages in this thread | | | Subject | Re: [patch] procfs/procps threading performance speedup, 2.5.62 | From | Albert Cahalan <> | Date | 22 Feb 2003 15:52:50 -0500 |
| |
On Thu, 2003-02-20 at 12:23, Ingo Molnar wrote:
> architecture-wise there is a difference, and i'd be > the last one arguing against a tree-based approach to > thread groups. It's much easier to find threads belonging > to a single 'process' via /proc this way - although no > functionality in procps has or requires such a feature currently.
Nope, the /proc/123/threads/246/stat approach is required. Without this, procps is forced to read _all_ tasks to group threads together. This is slow, prone to race conditions, more vulnerable to kernel bugs, and a memory hog.
FYI, thread grouping is required even if whole-process information is available. Many "ps" output formats need grouping, and it is desirable for many more.
I might as well mention that whole-process information includes the four fault counters and some indication that wchan data is multi-valued (a '*' must be displayed in that case). There may be more I haven't spotted yet.
Note that the recent /proc/*/wchan addition was botched. Caching is prevented due to race conditions. This could be fixed by changing the file format to contain: number, function name with optional: function address, file name, module name (next time, discuss such changes with an experienced procps developer first)
- 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/
| |