stability ?

[Valdis.Kletnieks at vt.edu]

On Thu, 04 Dec 2014 11:37:45 +0800, libin said:
>     Does anybody know what test should do before a patch added into the
> kernel ? I am interested in the method to prove the stability and performance
> of kernel , especially the stability .

That will of course be *heavily* dependent on the exact nature of the
patch.  The Linux kernel is developed with a "lots of small incremental
patches" philosophy.  As a result, most patches are relatively minor
and only require testing that they work - so if it compiles, boots, and
you test whatever function the patch does, that's sufficient.  Your webcam
now outputs RGB like it should, not GBR like it was? Excellent.  The ethernet
driver no longer crashes when it sees a packet that's exactly 1397 bytes
long? Great.  Package it up and submit it.

If you're adding new functionality, you of course want to test a bit more.

Boot the kernel, and let it run for a few days, make sure you don't have
any memory leaks or stray pointers or other crashes.  That's probably all
the testing most patches actually get.  And that's OK, most well-written
patches don't *need* more testing.

If you're ambitious and writing patches that are more invasive, get xfstests
and/or the Linux Test Project package and run those against your new kernel.
Note that you may need to write new test routines if you added new function.

If you're *really* hardcore, get 'trinity' and run that against your kernel.
Make sure to back the test system up first, it *can* eat your system.

The *real* problem is that the Linux kernel ends up getting used in lots
of weird configurations - far too many for any developer to test. And stability
issues come in two flavors:  Ones that kill your own box in an hour of light
use, and ones that only happen on a very small number of systems, none of them
yours.

I personally manage to trip over 3-4 bugs in linux-next each release cycle,
just because I do stuff on my Dell laptop that developers obviously didn't
have a way to test.  For instance, right now I'm trying to track down a
nasty bug in drivers/net/tun.c where it's pretty obvious that the guy who
wrote the commit tested what he could (he has a reputation of doing good
work), but the Juniper VPN software my employer uses gives it indigestion.
Wasn't any way for Herbert to test that one without a Juniper VPN box to
test against...

Linus had a *long* chase after one bug, that turned out two be two
instructions in the wrong order in an asm() statement, which would lead to
a system hang if an interrupt came in between the two instructions. So
there was a race condition window *literally* 2 cycles wide - and *one* user
had a workload that was able to pretty frequently drop an interrupt into
that billionth of a second window. Frequent as in "managed that impossible
shot several times a day"....

And the only real way to find that sort of weirdness is to get the patch into
linux-next and then have lots of linux-next testers with different use
cases....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141204/488f4eac/attachment.bin