lkml.org 
[lkml]   [2021]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] rt-tests-2.0
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

\
 
 \ /
  Last update: 2021-06-28 10:12    [W:0.069 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site