Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: [patch] procfs/procps threading performance speedup, 2.5.62 | Date | Mon, 24 Feb 2003 07:29:26 -0500 (EST) |
| |
> Albert, do you realize the simple fact that the procps > enhancements we did change absolutely nothing for the 'ps m' > case? All thread PIDs are still scanned and sorted.
That is a contradiction. There is no sorting with "ps m". Any ordering is from the /proc directory itself.
Sorting is not default because of the memory requirements and because there have been many kernel bugs that cause ps to hang when it hits a particular process. Sorting may mean that ps hangs or is killed before producing anything.
> And mind you, thread-directories do not change much in > this area - the PIDs within the thread-directory will > still be largely unsorted, and it will not make the > reading & sorting of 20K threads any faster.
That's OK. I need in-kernel grouping, not in-kernel sorting. It's fine to mix up thread order, but bad to interleave the threads of unrelated processes.
> so in fact _i_ came up with this whole issue 7 months ago. I just dont > share many of _your_ largely bogus arguments that seem to miss the point. > Can we finally stop this storm in a teapot?
Glad to, assuming you understand the importance of grouping. I hope I have now done a better job of explaining it. - 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/
|  |