From: Zhouping L. <zl...@re...> - 2011-01-24 07:01:43
|
Hi Garrett, Please review. when running a test case with setting -I options a number, it's useless. e.g when I run testcase/kernel/mem/hugetlbfs/hugemmap/hugemmap01, [root@dell-per805-01 hugemmap]# ./hugemmap01 -I 3600 -H /var/hugetlbfs/ hugemmap01 1 TPASS : call succeeded [root@dell-per805-01 hugemmap]# the test returned immediately, but no running for 3600 seconds, and other test cases all have this problem. I found it was that the variable stop_time in lib/parse_opts.c was integer that's not enough large, I changed it to a larger type(long long type), then it was okay, and support a larger number. Zhouping Liu Signed-off-by: Zhouping Liu <zl...@re...> --- lib/parse_opts.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/parse_opts.c b/lib/parse_opts.c index 338cbea..f8b1743 100644 --- a/lib/parse_opts.c +++ b/lib/parse_opts.c @@ -706,7 +706,7 @@ usc_test_looping(counter) int counter; { static int first_time = 1; - static int stop_time = 0; /* stop time in rtc or usecs */ + static long long stop_time = 0; /* stop time in rtc or usecs */ static int delay; /* delay in clocks or usecs */ int hertz=0; /* clocks per second or usecs per second */ int ct, end; /* current time, end delay time */ @@ -731,7 +731,7 @@ int counter; if (STD_LOOP_DURATION) { ct=get_current_time(); - stop_time=(int)((float)hertz * STD_LOOP_DURATION) + ct; + stop_time = (long long)hertz * (long long)STD_LOOP_DURATION + (long long)ct; } /* @@ -776,7 +776,7 @@ int counter; keepgoing++; } - if (STD_LOOP_DURATION != 0.0 && get_current_time() < stop_time) { + if (STD_LOOP_DURATION != 0.0 && (long long)get_current_time() < stop_time) { keepgoing++; } @@ -896,4 +896,4 @@ char **argv; exit(0); } -#endif /* UNIT_TEST */ \ No newline at end of file +#endif /* UNIT_TEST */ -- 1.7.1 |
From: Zhouping L. <zl...@re...> - 2011-01-25 02:22:52
|
Hi,Garrett, could you please review the patch, and give me your comments. any suggestions are welcome. Thanks a lot! ----- Original Message ----- > From: "Zhouping Liu" <zl...@re...> > To: ltp...@li... > Sent: Monday, January 24, 2011 3:01:32 PM > Subject: [LTP][PATCH] fix the -I option and enable a larger numble to I option > Hi Garrett, > Please review. > when running a test case with setting -I options a number, it's > useless. > e.g when I run testcase/kernel/mem/hugetlbfs/hugemmap/hugemmap01, > [root@dell-per805-01 hugemmap]# ./hugemmap01 -I 3600 -H > /var/hugetlbfs/ > hugemmap01 1 TPASS : call succeeded > [root@dell-per805-01 hugemmap]# > the test returned immediately, but no running for 3600 seconds, and > other test cases all > have this problem. I found it was that the variable stop_time in > lib/parse_opts.c was integer that's not > enough large, I changed it to a larger type(long long type), then it > was okay, and support a larger number. > > Zhouping Liu > > Signed-off-by: Zhouping Liu <zl...@re...> > --- > lib/parse_opts.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/lib/parse_opts.c b/lib/parse_opts.c > index 338cbea..f8b1743 100644 > --- a/lib/parse_opts.c > +++ b/lib/parse_opts.c > @@ -706,7 +706,7 @@ usc_test_looping(counter) > int counter; > { > static int first_time = 1; > - static int stop_time = 0; /* stop time in rtc or usecs */ > + static long long stop_time = 0; /* stop time in rtc or usecs */ > static int delay; /* delay in clocks or usecs */ > int hertz=0; /* clocks per second or usecs per second */ > int ct, end; /* current time, end delay time */ > @@ -731,7 +731,7 @@ int counter; > > if (STD_LOOP_DURATION) { > ct=get_current_time(); > - stop_time=(int)((float)hertz * STD_LOOP_DURATION) + ct; > + stop_time = (long long)hertz * (long long)STD_LOOP_DURATION + (long > long)ct; > } > > /* > @@ -776,7 +776,7 @@ int counter; > keepgoing++; > } > > - if (STD_LOOP_DURATION != 0.0 && get_current_time() < stop_time) { > + if (STD_LOOP_DURATION != 0.0 && (long long)get_current_time() < > stop_time) { > keepgoing++; > } > > @@ -896,4 +896,4 @@ char **argv; > exit(0); > } > > -#endif /* UNIT_TEST */ > \ No newline at end of file > +#endif /* UNIT_TEST */ > -- > 1.7.1 -- |
From: Garrett C. <yan...@gm...> - 2011-01-26 07:32:14
|
On Mon, Jan 24, 2011 at 6:22 PM, Zhouping Liu <zl...@re...> wrote: > Hi,Garrett, > > could you please review the patch, and give me your comments. > any suggestions are welcome. Wow, someone really lacked foresight when producing this API. Yes, there's a problem, but I disagree with your solution (in particular because long long isn't necessarily going to remain 64-bit in the future). I think that a fixed size type applied to all of these affect areas would be better (uint64_t -- the POSIX defined unsigned 64-bit integer [1]). Thanks, -Garrett 1. http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html |
From: Caspar Z. <ca...@ca...> - 2012-02-29 09:59:56
|
On 01/26/2011 03:32 PM, Garrett Cooper wrote: > On Mon, Jan 24, 2011 at 6:22 PM, Zhouping Liu <zl...@re...> wrote: >> Hi,Garrett, >> >> could you please review the patch, and give me your comments. >> any suggestions are welcome. > > Wow, someone really lacked foresight when producing this API. > Yes, there's a problem, but I disagree with your solution (in > particular because long long isn't necessarily going to remain 64-bit > in the future). I think that a fixed size type applied to all of these > affect areas would be better (uint64_t -- the POSIX defined unsigned > 64-bit integer [1]). > Thanks, > -Garrett /me bringing up with an old topic here... This problem comes out again (in cpuset01 test). I think we need someone to fix it. > > 1. http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html |
From: Zhouping L. <zl...@re...> - 2012-02-29 10:16:08
|
> > wrote: > >> Hi,Garrett, > >> > >> could you please review the patch, and give me your comments. > >> any suggestions are welcome. > > > > Wow, someone really lacked foresight when producing this API. > > Yes, there's a problem, but I disagree with your solution (in > > particular because long long isn't necessarily going to remain > > 64-bit > > in the future). I think that a fixed size type applied to all of > > these > > affect areas would be better (uint64_t -- the POSIX defined > > unsigned > > 64-bit integer [1]). > > Thanks, > > -Garrett > > /me bringing up with an old topic here... > > This problem comes out again (in cpuset01 test). I think we need > someone > to fix it. let me have a try again, I will make a patch later. Thanks, Zhouping |