Re: [ANNOUNCE] rt-tests-2.0

[John Kacur <jkacur@redhat.com>]

On Mon, 28 Jun 2021, Daniel Wagner wrote:

> Hi Mike,
> 
> On Sat, Jun 26, 2021 at 02:45:27PM +0200, Mike Galbraith wrote:
> > On Sat, 2021-06-26 at 13:47 +0200, Mike Galbraith wrote:
> > > On Sat, 2021-06-26 at 08:55 +0200, Mike Galbraith wrote:
> > > > On Fri, 2021-06-25 at 12:08 -0400, John Kacur wrote:
> > > > > I'm pleased to announce rt-tests-2.0
> > > >
> > > > Greetings,
> > > >
> > > > cyclictest seems to have grown an mlock related regression.
> > >
> > > Ok, chores done, I did a quick bisect/confirm.  I didn't go stare
> > > at rt_test_start() to ponder what the mlockall connection may be.
> >
> > Moving the call above "Get current time" stops it mucking things up.
> 
> Thanks a lot for your excellent report. rt_test_start does
> 
>   static char ts_start[MAX_TS_SIZE];
> 
>   static void get_timestamp(char *tsbuf)
>   {
>           struct timeval tv;
>           struct tm *tm;
>           time_t t;
> 
>           gettimeofday(&tv, NULL);
>           t = tv.tv_sec;
>           tm = localtime(&t);
>           /* RFC 2822-compliant date format */
>           strftime(tsbuf, MAX_TS_SIZE, "%a, %d %b %Y %T %z", tm);
>   }
> 
>   void rt_test_start(void)
>   {
>           get_timestamp(ts_start);
>   }
> 
> I'd say the tsbuf access is the one which triggers a pagefault.
> 
> John, I would suggest to move the rt_test_start() into rt_init() and
> take the timestamp at the execution start (as my initial version was). I
> think the additional pain in slightly more correct start timestamp
> (which is also not defined what it actually means in this context) is
> just not worth the effort.
> 
> Thanks,
> Daniel
> 

Send me a patch, and I'll have a look. The timerthread()function is
sensitive anyway, so it's probably a good idea not to put that kind
of thing there.

Note that the the code following the /* Get Current Time */
is getting the time, but you probably want something rougher that
you can call strftime on?

John