From: Albert Cahalan <albert@users.sf.net>
To: Roger Luethi <rl@hellgate.ch>
Cc: William Lee Irwin III <wli@holomorphy.com>,
linux-kernel mailing list <linux-kernel@vger.kernel.org>,
Paul Jackson <pj@sgi.com>
Subject: Re: [BENCHMARK] nproc: netlink access to /proc information
Date: 29 Aug 2004 19:31:17 -0400 [thread overview]
Message-ID: <1093822277.431.6919.camel@cube> (raw)
In-Reply-To: <20040829214150.GA5060@k3.hellgate.ch>
On Sun, 2004-08-29 at 17:41, Roger Luethi wrote:
> And FWIW, you don't need the "minimum set of /proc
> files needed to supply some required set of process
> attributes". Any set that supplies the required fields
> will do, and you can get an excellent approximation
> in O(n).
You got that, and you didn't like it.
I'm sure it wouldn't be hard to hack up some
special-case optimization for the cases you've
listed. As soon as I do so, you'll find another
special case. Ultimately, you ARE asking to have
procps solve the NP-hard set-covering problem.
There are several good reasons to not go down
that path. The potential for increasing numbers
of /proc files in the future is one. Another is
the very limited benefit; typical ps usage does
require much of that data. Maintainability is yet
another reason; ps does more than just spit out the
data. It is very useful to have a decent selection
of data items that will always be available for
process selection, sorting, and any other use.
The potential for adding bugs is great.
That said, I do at times tweak the code used to
select data sources. Perhaps I should add a new
/proc/*/basics file for the most popular items.
This would make fancy set-covering choices more
profitable.
next prev parent reply other threads:[~2004-08-29 23:32 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-27 12:24 [0/2][ANNOUNCE] nproc: netlink access to /proc information Roger Luethi
2004-08-27 12:24 ` [1/2][PATCH] " Roger Luethi
2004-08-27 13:39 ` Roger Luethi
2004-08-27 12:24 ` [2/2][sample code] nproc: user space app Roger Luethi
2004-08-27 14:50 ` [0/2][ANNOUNCE] nproc: netlink access to /proc information James Morris
2004-08-27 15:26 ` Roger Luethi
2004-08-27 16:23 ` William Lee Irwin III
2004-08-27 16:37 ` Albert Cahalan
2004-08-27 16:41 ` William Lee Irwin III
2004-08-27 17:01 ` Roger Luethi
2004-08-27 17:08 ` William Lee Irwin III
2004-08-28 19:45 ` [BENCHMARK] " Roger Luethi
2004-08-28 19:56 ` William Lee Irwin III
2004-08-28 20:14 ` Roger Luethi
2004-08-29 16:05 ` William Lee Irwin III
2004-08-29 17:02 ` Roger Luethi
2004-08-29 17:20 ` William Lee Irwin III
2004-08-29 17:52 ` Roger Luethi
2004-08-29 18:16 ` William Lee Irwin III
2004-08-29 19:00 ` Roger Luethi
2004-08-29 20:17 ` Albert Cahalan
2004-08-29 20:46 ` William Lee Irwin III
2004-08-29 21:45 ` Albert Cahalan
2004-08-29 22:11 ` William Lee Irwin III
2004-08-29 21:41 ` Roger Luethi
2004-08-29 23:31 ` Albert Cahalan [this message]
2004-08-30 7:16 ` Roger Luethi
2004-08-30 10:31 ` Paulo Marques
2004-08-30 10:53 ` William Lee Irwin III
2004-08-30 12:23 ` Paulo Marques
2004-08-30 12:28 ` William Lee Irwin III
2004-08-30 13:43 ` Paulo Marques
2004-08-29 19:07 ` Paul Jackson
2004-08-29 19:17 ` William Lee Irwin III
2004-08-29 19:49 ` Roger Luethi
2004-08-29 20:25 ` William Lee Irwin III
2004-08-31 10:16 ` Roger Luethi
2004-08-31 15:34 ` [BENCHMARK] nproc: Look Ma, No get_tgid_list! Roger Luethi
2004-08-31 19:38 ` William Lee Irwin III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1093822277.431.6919.camel@cube \
--to=albert@users.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=rl@hellgate.ch \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.