| View previous topic :: View next topic |
| Author |
Message |
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
 Posted: Fri Feb 18, 2011 5:26 pm Post subject: Setting up automated test |
 |
|
I'm interested in collecting some information on the effects of changing some of the vm settings {such as vm.swappiness et all} in the kernel.
I'm not really happy with some of the 'tasks' people have used to test these settings as I feel they are highly artificial and therefore not relevant to actual usage. i.e. Multiple loops using 'dd' is not, in my opinion, relevant to nearly anything I ask most any computer to do.
I have conceived of a test methodology which I expect to give me some of the information I'm looking for, but I can't figure out how to implement it. A regular 'bash' script will not do because I expect failures in the form of 'segfaults'.
What I would like is to start:
Because I know that 'gcc' will fail with a segfault when it runs out of memory, I want to automatically respawn the emerge with: each time a segfault occurs.
I already know from experience that resuming emerge will work and that the package which gcc segfaulted will complete and continue onto the next package.
My problem is that I don't know how to set this up. I believe, in theory, that it should be possible but I really lack the knowledge to be able to do it.
Some refinements: Obviously, I'd like to collect timing information. I'd also like to collect 'free -m' information at each segfault occurrence. I would initiate each test run by rebooting to a CLI login. The 'trick' here is that the start of the process is different from the respawn of the process. i.e. "emerge -e system" versus "emerge --resume".
I did think of using the "--keep-going" modifier, but I don't believe that works after a segfault. At least, I'm not sure that it should. I don't know if it would or wouldn't work. I guess I'll try to find out at some point but I really don't expect it to.
Information I'm looking to collect includes the behavior of {among others} vm.swappiness, vm.overcommit_memory vm.overcommit_ratio, vm.min_free_kbytes. I can see the comments in the source code for what these are for and I have read the comments of people making some changes to these settings, but I want to collect information with is a bit more systematic and I want to see what some of the real life interactions are.
Any suggestions?
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
 |
TJNII
l33t
Joined: 09 Nov 2003
Posts: 648
Location: for(;;);
|
| Posted: Fri Feb 18, 2011 11:12 pm Post subject: |
|
|
I would recommend scripting this in expect. I personally use expect itself, where program control is coded in TCL, or you can use the expect plugins for Perl or Python. (The test group where I work uses Perl and expect for stuff like this.) With expect you can basically script control of a bash session to kick off emerge, catch segfaults, catch failures, log things, and what have you.
If you get really slick you could even make it modify your kernel settings, rebuild the kernel, reboot the system, run the test, and repeat. For this you would obviously need a second box that runs the script. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
