Messages in this thread | | | Date | Fri, 27 Aug 2004 09:23:08 -0700 | From | William Lee Irwin III <> | Subject | Re: [0/2][ANNOUNCE] nproc: netlink access to /proc information |
| |
On Fri, Aug 27, 2004 at 02:24:12PM +0200, Roger Luethi wrote: > Problems with /proc > =================== > The information in /proc comes in a number of different formats, for > example: > - /proc/PID/stat works for parsers. However, because it is not > self-documenting, it can never shrink, It contains a growing number > of dead fields -- legacy tools expect them to be there. To make things > worse, there is no N/A value, which makes a field value 0 ambiguous. > - /proc/pid/status is self-documenting. No N/A value is necessary -- > fields can easily be added, removed, and reordered. Too easily, maybe. > Tool maintainers complain about parsing overhead and unstable file > formats. > - /proc/slabinfo is something of a hybrid and tries to avoid the > weaknesses of other formats. > So a key problem is that it's hard to make an interface that is both > easy for humans and parsers to read. The amount of human-readable > information in /proc has been growing and there's no way all these > files will be rewritten again to favor parsers.
These are many of the same issues raised in rusty's "current /proc/ of shit" thread from a while back.
On Fri, Aug 27, 2004 at 02:24:12PM +0200, Roger Luethi wrote: > Another problem with /proc is speed. If we put all information in a few > large files, the kernel needs to calculate many fields even if a tool > is only interested in one of them. OTOH, if the informations is split > into many small files, VFS and related overhead increases if a tool > needs to read many files just for the information on one single process. > In summary, /proc suffers from diverging goals of its two groups of > users (human readers and parsers), and it doesn't scale well for tools > monitoring many fields or many processes.
There are more maintainability benefits from the interface improvement than speed benefits. How many processes did you microbenchmark with? I see no evidence that this will be a speedup with large numbers of processes, as the problematic algorithms are preserved wholesale.
-- wli - 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/
| |