Re: __profile_frequency

[Roland McGrath <roland at redhat dot com>]

> Um, so how's 
> 
> 45        tim.it_interval.tv_sec = 0;
> 46        tim.it_interval.tv_usec = 1;
> 47        tim.it_value.tv_sec = 0;
> 48        tim.it_value.tv_usec = 0;
> 49        __setitimer(ITIMER_REAL, &tim, 0);
> 50        __setitimer(ITIMER_REAL, 0, &tim);
> 51        if (tim.it_interval.tv_usec < 2)
> 52          return 0;
> 53        return (1000000 / tim.it_interval.tv_usec);
> 
> supposed to work?  AFAICS there's no reason for the kernel 
> (1) not to round down instead of up and (2) not do something
> else legal like schedule in between the two __setitimer calls.

In the original BSD setitimer (4.2 or 4.3 BSD), this was the documented way
to find the granularity of the timer.  I don't know one way or the other
whether Linux has ever supported this aspect of the setitimer interface,
and BSD no longer documents it.

(1) is specified by 1003.1-2003, and BSD (the origin of the interface)
always behaved that way.  (2) does not matter, because you are looking at
the reload value, not the current value.  

The specification says "the actual timer value shall be rounded up".  This
could be construed either to say that getitimer (and the equivalent
querying part of a setitimer call, as in the example) must report the
rounded value, or to say that the actual delay time used must be rounded up
but getitimer/setitimer can report the supplied value.  There is no way to
interpret the second setitimer returning tim.it_interval.tv_sec+usec==0 as
anything but a spec-violating bug.

> Why wouldn't this be the same as __getclktck?

It should.  This use of setitimer is the traditional method when there is
no explicit kernel facility for telling you the granularity of the itimers.
Linux supplies AT_CLKTCK to tell you, and __getclktck uses that.


Thanks,
Roland