Hi Bian, to make a conclusion for this thread: I have tested ksm cases and Pingtian's patch for many times, it worked well. If it doesn't work on your system, please check:
1) Have you disabled ksm and ksmtuned before test? it will very easy to get "stopped before echo 2 > ksm/run" due to ksmtuned behavior if you keep them running. 2) Have you tried with a kernel containing this upstream commit: 2919bfd0758257c469abef8c26c3e516bbebb851 ? Without the patch in this commit, your test might fail as well. Thanks, Caspar On 04/08/2011 02:07 PM, Han Pingtian wrote: > On Fri, Apr 08, 2011 at 01:31:59PM +0800, Bian Naimeng wrote: >> >> >> Han Pingtian wrote: >>> On Thu, Apr 07, 2011 at 01:52:40PM +0800, Bian Naimeng wrote: >>>> >>>> CAI Qian wrote: >>>>> ----- Original Message ----- >>>>>> Qian Cai wrote: >>>>>>> On 2011-4-4, at 0:47, Bian Naimeng <[email protected]> wrote: >>>>>>> >>>>>>>> There are some problem in ksm tests. >>>>>>>> >>>>>>>> 1. We should break the test when checking is failure. >>>>>>> No, this is not the intention. The design here is to run all tests >>>>>>> to check for all stats to give a full picture even if the a single >>>>>>> failure has been observed. This type of the failures do not prevent >>>>>>> the rest of the tests from running, so there is no need to stop the >>>>>>> tests now which also give more insight to track down root causes. >>>>>> Various reason can make checking failure, someone can make the test >>>>>> hangup. >>>>>> I did this test on RHEL5, i found ksmd stopped before doing "echo 2 > >>>>>> /sys/kernel/mm/ksm/run", >>>>>> so group_check will be hanged on "new_num < old_num * 3". >>>>>> >>>>>> So, i think we should break the test if "run" is not expecting. >>>>> What happened if you run the tests for a recent upstream kernel? There >>>>> are some patches for ksm recently merged upstream. If the problem still >>>>> persistent, please paste the EXACT OUTPUT from the ksm01 test. If it is >>>>> hung, please upload sysrq-t output somewhere. >>>>> >>>> Maybe there are some bugs in the RHEL6's kernel, but the purpose of this >>>> patch >>>> is not to workround these bugs, i want to fix the test's bug. >>>> >>>> Would you explain to me why we do this loop "while (new_num < old_num * >>>> 3)" in >>>> group_check, i think "while (new_num < old_num + 3)" is better. >>>> >>>> Some time ago, the following patch insert this loop. >>>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTi%3Dg%3DojJu0m%2B556rnekYenRTXtX%2BVBOj%3DrPmnjSw%40mail.gmail.com&forum_name=ltp-list >>>> >>>> The changelog of this patch said "we should wait 3~5 increments of the >>>> /sys/kernel/mm/ksm/full_scans before checking ksm* testcases's results", >>>> but >>>> it do "while (new_num < old_num * 3)" actually. >>> I made a mistake. The code is what I wanted to do, but the changelog was >>> wrong. When testing the new ksm patch, the developer told us we must >>> wait 3~5 times increments of the number before checking testing >>> results. So I coded to wait til new_num >= old_num * 3 before checking >>> the results. >>> >> >> The bigger old_new is, the longer time test takes, it's strange. > I agree that it's strange. But it seems that we have to do this way. >> >>> About 'echo 2 > /sys/kernel/mm/ksm/run' problem, I have tested it with >>> ksm01. >>> If I run the 'echo 2 > /sys/kernel/mm/ksm/run' before issue ksm test, >>> the content of /sys/kernel/mm/ksm/run will be changed to 1 and the test >>> can finished successfully. >> >> I think we shoud not care this. > Yep, I think so. >> >>> Only if I echo the 2 between the testing process, >>> ksm01 will hang up. On that time, new_num will be zero, so your plus 3 >>> method won't work either. So what should we do in this circumstance? >>> >> >> Please look at my patch, after stopping ksmd in the testing(echo 2 > >> /sys/kernel/mm/ksm/run or >> echo 0 > /sys/kernel/mm/ksm/run), group_check will skip waiting at the loop >> "new_num >= old_num * 3". >> > Run 'echo 2 > /sys/kernel/mm/ksm/run' before calling group_check() won't > cause the while loops infinitely, because old_num and new_num would be all > zero before the while, so new_num == old_num * 3, the while won't be > ran. >> Regards >> Bian >> >>> Thanks. >>> >>> Han Pingtian >>>> Regards >>>> Bian >>>> >>>>> CAI Qian >>>>> >>>>>>>> 2. The condition "new_num < old_num * 3" seems uncomfortable, i >>>>>>>> think >>>>>>>> it should be "new_num < old_num + 3" >>>>>>> I don't understand. What error did you see from the testing output? >>>>>> Sometimes, the old_num is a big number, so it takes long time in this >>>>>> loop, >>>>>> i don't understand the purpose. >>>>>> Would you explain to me why we expect this condition "new_num < >>>>>> old_num * 3". >>>>>> >>>>>>>> 3. After stopping ksm(echo 2 > /sys/kernel/mm/ksm/run), the ksmd >>>>>>>> will stop scaning pages, so looping in "new_num < old_num * 3" >>>>>>>> is wrong. >>>>>>> Ditto. >>>>>>> >>>>>> After stopping ksm, looping in "new_num < old_num * 3" will make the >>>>>> process hang up, >>>>>> because new_num does not be increased. >>>>>> >>>>>> Regards >>>>>> Bian ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
