kernel/accounting question ...
by William W. Austin
(I know that this question might be more reasonable on a kernel list,
but a while back I posted the question twice and got no answers.)
The acct struct is defined in /usr/include/sys/acct.h includes both
ac_io and ac_rw for bytes transferred and blocks read or written,
respectively. Fair and good - works (on paper) similarly to unix,
solaris, hp-ux, etc.
However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw
(blocks) are always set to 0 by these two lines:
ac.ac_io = encode_comp_t(0 /* current->io_usage */);
ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
For most purposes, this probably wouldn't be an issue, but I also do
extensive performance analysis on several platforms and have written a
fairly compresive accounting package (as a wraparound for psacct or as
a standalone) including both an improved acctcom and a built-in
reporter for it.
Does anyone know wby the kernel zero's out the bytes transferred data?
(Overhead comes to mind.) Not that it makes a huge differnce for my
purposes (I had to write some wraparound code to make a
"best-guestimate" about the data I'm missing), but curiosity is bugging
me now. When I compile my program on other OS's I get useful data for
char and block i/o and I'd like to find out whether there is something
obvious that I'm just totally missing here...).
Thanks
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
14 years, 4 months
acctcom for linux
by William W. Austin
I recently made several updates to a Linux version of of acctcom
(actually another accounting add-on package) which I've been using for
several years, and one of the people testing it asked a question which
I cannot answer. I'm hoping that someone on this list can give me some
info.
I have previously (over a year ago) asked on both this and a couple of
kernel lists (several times there) about this issue, but nobody has
ever answered. So if you have any info about this, I'd really
appreciate it.
As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are
presumably counts of characters transferred and blocks read/written
respectively.
However, in the kernel code, the ac_io is set to 0 and the ac_rw gets
set to (ac_io/512) or some such - it is set to 0 as well (and thus
these are always reported as 0 in process accounting records. not good
if you're trying to measure them...).
Does anybody know why this is done that way? A long time ago (IIRC
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the
kernel code but was not successful (I finally produced a bootable
kernel, but it was unstable. Then I changed jobs, got swamped at work,
and eventually gave up).
As I said above, I have previously asked about this issue without
success, and I have essentially given up changing or "fixing" it.
But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's
just too much work for too little added value), I'd really appreciate
knowing the reason. Curiosity and the cat and all that ...
Thanks
- Bill
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
14 years, 4 months
Possible wrong versions tagged into f12-final
by Quentin Armitage
I've noticed what might be a couple of anomalies regarding which
versions of packages have been tagged into f12-final.
freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but
0.9-10.fc11 tagged has been tagged into f12-final.
gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but
0.8.14.3.fc11 has been tagged into f12-final. It appears that
0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12
rebuild).
Quentin Armitage
14 years, 4 months
Packages looking for new owners
by Trond Danielsen
Hi everyone,
it is becoming clear to me that I can no longer provide the collection
of packages I maintain the love and care that they deserve. If only
there were more hours in a day, but the current situation does no
leave much room for volunteer work on free software :-(. Hopefully I
will find time in the future to return to Fedora related work
The list if packages I maintain is available here:
https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner
I don't mind keeping libopenraw, avrdude and uisp unless anyone
_really_ want to maintain these packages.
Best regards,
--
Trond Danielsen
14 years, 4 months
Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
by Terry Barnaby
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones).
All of these bar 1 has problems with the graphics (X11 lockups, system lockups
and other problems) mainly in 3D but also in 2D.
I still am using F8 on most of my systems as the Graphics systems have not
been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself
have worked on and fed back issues as time and ability allow. During F11
I helped with some issues, but unfortunately none of these made it back into
updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system
libraries etc in Fedora. The core issues most people seem to be facing is
Graphics and Sound issues. Obviously a major issue with Graphics is the sheer
number of different graphics chip sets in use and the lack of documentation
for quite a few of them. Due to this it requires a lot of user testing and
feedback to get these issues sorted out. Unfortunately the very fast
Fedora new release schedule gets in the way of getting this testing done
and things do not get fixed prior to a new release which introduces yet
another set of problems. The new release speed also uses a lot of
developer and user time in just managing to create a new release and
updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to
be close to the leading edge, but this has to be balanced with usability
otherwise there will be few people actually using it in anger and thus
actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing
and updating the F12 release ? This will concentrate developers and users into
one system release. Similar to the pre-release test days we could have
post-release test days. For example a Graphics test day for F12 where
a certain set of tests with a test suite and a set of well known applications
could be run. As F12 would be out longer, more people could participate in this.
If a commitment, all round, to producing updates fixing the issues in F12 were
made, I think more people would be willing to participate as users could
expect to see a stable system for their efforts.
14 years, 4 months
