Linux: Tracking Kernel Usage

Submitted by Jeremy
on August 30, 2005 - 6:07am

Andrea Arcangeli [interview] offered a tiny Python script called KLive for tracking kernel usage. He explained, "during the Kernel Summit somebody raised the point that it's not clear how much testing each rc/pre/git kernel gets before the final release." The simple script is a proof of concept, and is designed to be started at boot time. It collects a small amount of information about your computer (kernel version, amount of RAM, number of CPUs, speed in megahertz, and number of devices) and routinely sends this data to a central server. The collected data is then displayed in a simple chart, with the hope that it provides a useful estimate as to how much testing each kernel is getting.

Running Andrea's KLive script requires the Twisted Python networking framework. Once installed, you simply execute "twistd -oy klive.tac" and the script begins running in the background. Ideally the script would be launched automatically at boot time. Andrea noted, "I setup a server to track automatically the amount of testing that each kernel gets. Clearly this will be a very rough approximation and it can't be reliable, but perhaps it'll be useful." He went on to note that if the project was considered useful, it might make sense to get rid of the userland script and move everything into the kernel, making it a configurable option to simplify use. He adds, "if this won't be useful, the time I spent on it is very minor so no problem ;)."


From: Andrea Arcangeli [email blocked]
To:  linux-kernel
Subject: KLive: Linux Kernel Live Usage Monitor
Date:	Tue, 30 Aug 2005 05:09:59 +0200

Hello,

During the Kernel Summit somebody raised the point that it's not clear
how much testing each rc/pre/git kernel gets before the final release.

So I setup a server to track automatically the amount of testing that
each kernel gets. Clearly this will be a very rough approximation and it
can't be reliable, but perhaps it'll be useful. If this won't be useful,
the time I spent on it is very minor so no problem ;).

All the details can be found in the project website:

	http://klive.cpushare.com/

Full source (server included) is here:

	http://klive.cpushare.com/downloads/klive-0.0.tar.bz2

To run the client:

	wget http://klive.cpushare.com/klive.tac

Then at every boot (like in /etc/init.d/boot.local):

	twistd -oy klive.tac

In theory we could get rid of the client entirely and make it a kernel
config option, but I've no idea if this project is useful, so I don't
want to spend too much time on it at this point.

Thank you.



Related Links:

Into the kernel?

Anonymouse! (not verified)
on
August 30, 2005 - 8:05am

You often hear agruments that X and Y don't belong in the kernel.
It was one of the reasons for removing devfs, for example...
So why put _THIS_ in? It's fine as a userland script...

Use the kernel as a distribution vector only

Mr_Z
on
August 30, 2005 - 8:47am

You could make it a userland process that's distributed with the kernel. After all, things like menuconfig, ksymoops and certain patch update scripts are all userland things distributed with the kernel.

A different interesting use of this sort of coverage tracking is that the kernel developers can maybe use it to determine what features are actually getting used, and which are just being carried around.

Distribute it with the kernel

Anonymous- (not verified)
on
August 30, 2005 - 8:58am

I think Alan has a good suggestion:

Wrong way around - you need to let people turn it on. Perhaps distribute
it with the kernel so you can

make register
[Reports hardware, stashed a unique sha-1 hashed cookie]
[Asks for permission, installs UDP ping daemon]

make unregister

but it would have to be opt in. That might lower coverage but should
increase quality, especially id the id in the cookie can be put into
bugzilla reports, and the hardware reporting is done so it can be
machine processed (ie so you can ask stuff like 'reliability with Nvidia
IDE')

Right. But still this is a fe

Anonymöus (not verified)
on
August 30, 2005 - 1:41pm

Right. But still this is a feature I sure would not enable on my machine.
I havent installed the debian popularity contest stuff either btw.

But then there is the difference from free software to non-free: With other OSes you're not asked if you want such a feature ;-)

I guess it's testing kernels

Mark Williamson
on
August 30, 2005 - 7:14pm

I guess it's testing kernels only: rc kernels, maybe mm kernels. It's certainly bloat you wouldn't want in a real kernel but I suppose if it's not enabled in release kernels it's not so bad. The point is to measure how much testing is being done on this code...

I think it's relatively unfortunate that the current script requires both Python and the Twisted framework, just to report what kernel you're testing. Although it's not very tasteful I guess adding a reporting tool in the kernel could be the a reasonable, pragmatic solution.

What are you talking about? I

Anonümous (not verified)
on
August 31, 2005 - 11:44pm

What are you talking about? I don't see anyone mention anything but python script!?

Great Idea!

Anon (not verified)
on
August 30, 2005 - 5:58pm

I think this is a great idea. I think this will help "new" platforms such as x86_64, dual core, etc., get the better supprt. I've had several bugs in the past year or two that might havee been addressed faster if the developers had a better idea of what configurations were being run by linux users. I think that it can be a problem, that kernel developers underestimate the usage of various configurations. I would certainly participate, if nothing more than a way to "vote" and make sure that my hardware config get's counted and hopefully supported.

Duplicate effort ?

Moltonel (not verified)
on
August 31, 2005 - 2:38am

This looks a lot like LiSt (http://www.linux-stats.org/), which collect the same info and a bit more, with a very straightforward bash script.
It was originally gentoo-specific but not any more.

Also Linux Counter

eru
on
September 5, 2005 - 8:01am

The Linux Counter project also collects
kernel version statistics.
See
http://counter.li.org/reports/systemstats.php

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.