Re: KLive: Linux Kernel Live Usage Monitor

[Andrea Arcangeli <andrea@cpushare.com>]

On Tue, Sep 06, 2005 at 12:05:07AM +0200, Marc Giger wrote:
> Hi Andrea
> 
> Two little details:
> 
> The following line does not print what you expect on
> alpha's:
> 
> MHZ = int(re.search(r' (\d+)\.?\d?',
>                     os.popen("grep -i mhz /proc/cpuinfo | head -n
> 1").read()).group(1))

Thanks for reminding me about it ;)

> Second, you should mention somewhere that it needs at minimum twisted
> 1.3.0 to work correctly, did you?

I didn't, I actually hoped it would work with older twisted too ;)

> Oh, another point:
> Some of my machines have long uptimes, and I won't it reboot
> to just match the klive runtime. So the reported uptime
> is (in my cases) far away from true.

You don't need to reboot them, however I can't trust past uptimes or it
would be way too easy to fake the results (it's still easy but it takes
a lot more effort).

> It is very interesting to see how often a vanilla/-git/-mm etc kernel is
> tested. [..]

This is the objective yes.

> [..]. Perhaps klive could be extended to automatically report oopses
> and/or other troubles if possible. What abut reporting core features
> which are used on the machine like fs, scheduler, raid, lvm etc, so
> that the devs can see which subsystem got a lot testing and what is
> not used much?

So it sounds like the next thing to do is to extend the protocol to add
an _optional_ reporting of more info on the subsystems and hardware
involved (turned off by default). About the oopses that will require
kernel changes, and as per previous emails that'd be a very interesting
feature to enable optionally too (via sysctl etc..).

The old protocol (number 0) will stay, infact that will remain the
default.

Thanks.