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
