Hi Shane, Thanks for bringing out the ghost out of the coffin. This was an issue i wanted to discuss long back. Now that you have opened up the discussion, let me put forth my idea.
I want the LTP test cases to remain as general as they can be. Let the ways to run the test cases be modified either during build/install time, or during run time, or both. This can be achieved by creating directories say: ltp/archs/, ltp/archs/arm/ ltp/archs/sh/ ltp/archs/* and then create some patch files like: ltp/archs/arm/during-build.patch ltp/archs/arm/during-run.patch 1) If the test cases need to be built with different parameters/identifiers/variables/ifdefs, for a particular architecture, then let ltp/Makefile detect that and apply say ltp/archs/*/during-build.patch before it starts to build. So, we get binaries built and suited to run for that architecture. 2) If the test cases need to be run with different parameters, then let the ltp/runltp detect that particular architecture and apply ltp/archs/*/during-run.patch on ltp/runtest/* command files and then run the tests. With these we will be able to retain the generalization of the tests and also run specific instances of tests depending on the architecture, memory, FS size requirements. What i would require is somebody should send me regular patches to update the ltp/arch/*/*.patch for their particular architectures. So you think that this is a feasible IDEA ? Regards-- Subrata and then have On Thu, 2008-10-16 at 14:27 -0400, Shane Volpe wrote: > All, > > There are several tests in ltp that, by default, use too much memory > and cause small embedded systems to run out of RAM leading to kernel > oom-killer dumps. I have been able to identify most of these tests on > my system and tweak by trial and error the input parameters to allow > the test to still run with out causing a omm-killer dump. > > Here are two examples that I have had to address to date: > > 1.)Fix float tests by adding -n 15 to limit the number of treads to 15 > which by default is set to 20. > > Modified runtest/math, runtest/ltplite and runtest/stress.part2 as follows: > Changed: > float_bessel cd $LTPROOT/testcases/bin; float_bessel -v > float_exp_log cd $LTPROOT/testcases/bin; float_exp_log -v > float_iperb cd $LTPROOT/testcases/bin; float_iperb -v > float_power cd $LTPROOT/testcases/bin; float_power -v > float_trigo cd $LTPROOT/testcases/bin; float_trigo -v > > to: > float_bessel cd $LTPROOT/testcases/bin; float_bessel -v -n 15 > float_exp_log cd $LTPROOT/testcases/bin; float_exp_log -v -n 15 > float_iperb cd $LTPROOT/testcases/bin; float_iperb -v -n 15 > float_power cd $LTPROOT/testcases/bin; float_power -v -n 15 > float_trigo cd $LTPROOT/testcases/bin; float_trigo -v -n 15 > > 2.) Fixed hackbench tests by reducing number of threads/processes active. > Modified runtest/sched: > changed: > hackbench01 hackbench 150 process 1000 > hackbench02 hackbench 20 thread 1000 > to: > hackbench01 hackbench 5 process 1000 > hackbench02 hackbench 10 thread 1000 > > > There are a handful of other tests I had to modify, but the point of > this email is not to detail everything but instead to start a > discussion on how to track *good* settings for different memory > configurations (16MB, 32MB, 64MB...). I can think of a couple > possible solutions: > 1.) a log somewhere (wiki maybe) of system resources (SDRAM) verses > test parameter tweaks so others have an idea of reasonable parameters > for the memory intensive tests. > 2.) Multiple runtest files based on memory size, I personally don't > like this option as it makes a lot of extra files to maintain, but it > still is an option. > 3.) A more advanced solution would be to have ltp detect the available > RAM and adjust these test cases automatically. > > Sorry if this has already been discussed, I searched LTP but have not > found any postings that address this. > Regards, > Shane > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
