[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210628081135.l7yvya7iaygb23ye@beryllium.lan>
Date: Mon, 28 Jun 2021 10:11:35 +0200
From: Daniel Wagner <wagi@...om.org>
To: Mike Galbraith <efault@....de>
Cc: John Kacur <jkacur@...hat.com>,
RT <linux-rt-users@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Clark Williams <williams@...hat.com>,
Daniel Wagner <dwagner@...e.de>,
Johnathan Schwender <schwenderjonathan@...il.com>,
Peter Xu <peterx@...hat.com>
Subject: Re: [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
Powered by blists - more mailing lists