Messages in this thread | | | Subject | Re: [PATCH v2 1/3] process cputimer is moving faster than its corresponding clock | From | Olivier Langlois <> | Date | Mon, 29 Apr 2013 14:54:27 -0400 |
| |
On Mon, 2013-04-29 at 14:31 -0400, KOSAKI Motohiro wrote: > (4/29/13 2:20 PM), Olivier Langlois wrote: > > > >> > >>>> I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I have > >>>> no seen any issue in this accounting. > >>> > >>> glibc launch a helper thread to receive timer signal and will also > >>> create a new thread upon signal reception when a timer is created with > >>> sigev_notify = SIGEV_THREAD; > >>> > >>> please see: > >>> > >>> glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_create.c > >>> glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_routines.c > >> > >> I know. I taled thread exiting. not thread creating. And, as far as I can see, only test sig1 can fail, > >> not thr[12]. > >> > > Apart from glibc helper thread, the threads created for handling timer > > firing all do exit immediatly as soon as user callback returns. > > And, libc ensure its exiting finished before starting actual tests. Why such thread exiting > affect timers code? It shouldn't. becuase signal.cputimer is initialized timer_settime(). > The initialization is incorrect, we should fix initialization.
It doesn't have anything to do with initialisation.
Quick Quiz #1: How does the cputimer tick? Answer: With calls to account_group_exec_runtime()
Every task updates occuring after release_task() has been called in do_exit() (scheduler ticks or the task final schedule() call) will be lost because tasks stats are added to the global group stats located in the signal struct in release_task() So every update after release_task() will be lost but account_group_exec_runtime is still called.
Tasks that go in zombie state are fine because release_task() will be called later. Autoreap task (those with CLONE_THREAD ie: pthreads) calls release_task() before the last context switch. Please do read kernel/exit.c.
Hence cputimer advance faster than the process clock.
Hence the POSIX compliance from your pseudo code does not hold
sighandler(){ t1 = clock_gettime() }
t0 = clock_gettime() timer_settime(timeout); ... wait to fire assert (t1 - t0 >= timeout)
> > > > I count 12 thread exits during tst-cputimer1 execution. The errors do > > add up hence you're more likely to see errors after 2.5 sec and up from > > start of execution. I have seen sig1, thr[12] fails. I see no reason why > > one could not fail.
| |