/proc/stat looks bit diffrent in kernels 2.6. it separates I/O waits and interrupt services from idle time and some programs (like kcpuload) interprets it as cpu usage (so they always print 100% on hard disk usage). i've created patch which fixes that problem
Created attachment 58682 [details, diff] described patch. works fine on my system with kernel 2.6 and without smp. it should also work with 2.4 kernels (and should work on systems with smp). note however i havn't tested it on such systems
Thanks for the patch. The best thing to do would be to submit it to kcpuload author so that it can be reviewed and eventually included. ...but looking at it, it seems this package is not maintained anymore, I cannot even find a homepage, or a place where I can download it! Given this situation, maybe the best thing to do is to remove kcpuload from portage?
yes - i know about it. i've also tried to search for it's homepage... but i think it's nice application and it's one of those, which doesn't have to be constantly upgraded. this small patch should be enougth at least until next kernel branch i suppose. i don't know what's gentoo's policy for unmaintained software but personally i like those one and i would like to have it in portage
Well, there are a lot of dead/unmaintained projects in portage, but this one does not even has a public uri where the tarball can be found... even if there isn't a precise list of requirements to be in portage, this package goes beyond the limit... We can wait a bit to see if something new comes up (have you tried writing a mail to the author?), and then we will see what to do.
ok - i'll try to contact with author and let you know if he answered in few days
Added to package.mask, pending removal.
I think the maintainer of this now should be me... It was in my plan rewriting it after KNetLoad was complete (and I'm stil battling to see why the snmp support works once, twice, and then stops until you restart kicker), but I'm not sure if this is going to be of help or not.. KSim is a good replacement also if it's a bit too invasive, and probably KCpuLoad would be better in a suite of applets for hardware monitoring. Marcin if you want, ask for writing access to KDE's SVN and you can fix the code directly on kdeextragear, using the new KNetLoad code to replace the old graph code from KCpuLoad.
Removed from portage for now, it will be readded once someone opens a project at sourceforge or kde-apps for it and takes over maintainership.
i dont even see this issue, why was this ever removed? has anyone tested his patch (im reluctant to try it since i dont see the issue) does the reporter still see the issue on a current 2.6 kernel? yes it's a personal favorite since there is no replacement especially :)
Gregorio (comment #8): since i've became gentoo developer in meantime, i like that applet and i don't think it can be very problematic, i think i'll maintain it (if Diego won't). Daniel (comment #9): in kernels from 2.2 and 2.4 branches cpu time was divided on 4 categories: system, user, nice and idle. basically: the first three showed cpu time spent on diffrent kinds of work, and idle = 100% - system -user -nice. in kernel from 2.6, there are 3 additional categories: iowait, irq and softirq. we can omit irq and softirq (since they take really few time), but iowait is problematic. if program count idle time as i write above (and almost each if not all programs do so), then all i/o based operation are couted as cpu busy time, which is not true. try for example command 'find', which reads a lot of data from disk (iowait), but doesn't need much cpu for that. without patch posted by me, kcpuload'll show you, that you're using your cpu in 100% until the command ends, which is definitly not true. with that patch you'll get only few percents
argh - i mean total cpu time was counted as system + user +nice +idle, not idle = 100% -system - user - nice (and we should add iowait (and irq/softirq) to total cpu time now). sorry - it's a bit late here:|
Moving this over directly to mkay.
There's no kcpuload in the tree any more.