Web lists-archives.com

Re: The timerfd functions slow down emacs




On 2/23/2019 4:01 PM, Corinna Vinschen wrote:
> On Feb 23 20:48, Ken Brown wrote:
>> On 2/23/2019 2:15 PM, Corinna Vinschen wrote:
>>> Below's the NSSTC I used to test my timerfd implementation (based on
>>> another STC to show a problem in POSIX timers).  From what I can tell it
>>> works as desired.  If you find a problem, please point it out or send a
>>> patch.
>>
>> Thanks, that saved me a lot of time.  I was in the process of creating a test
>> case when your mail arrived.
>>
>> Your test works fine.  For example:
>>
>> $ gcc timerfd_test.c -o timerfd_test
>>
>> $ ./timerfd_test.exe 3 1 10
>> 0.000: timer started 52379
>> 2.988: 52379 read: 1; total=1
>> 3.988: 52379 read: 1; total=2
>> 4.989: 52379 read: 1; total=3
>> 5.987: 52379 read: 1; total=4
>> 7.001: 52379 read: 1; total=5
>> 7.987: 52379 read: 1; total=6
>> 9.001: 52379 read: 1; total=7
>> 9.987: 52379 read: 1; total=8
>> 10.987: 52379 read: 1; total=9
>> 11.997: 52379 read: 1; total=10
>>
>> But if I change CLOCK_MONOTONIC by CLOCK_REALTIME in the call to timerfd_create,
>> then I get the following:
> 
> Only in timerfd_create?  Not in clock_gettime?  If you don't
> do that, you're using a different clock with entirely different
> values for the starttime.
> 
> Actually, this testcase started with CLOCK_REALTIME in both calls.
> If I revert to that, I get:
> 
> )$ ./timerfd 3 1 10
> 0.000: timer started 644
> 3.001: 644 read: 1; total=1
> 4.001: 644 read: 1; total=2
> 5.017: 644 read: 1; total=3
> 6.001: 644 read: 1; total=4
> 7.001: 644 read: 1; total=5
> 8.009: 644 read: 1; total=6
> 9.002: 644 read: 1; total=7
> 10.001: 644 read: 1; total=8
> 11.010: 644 read: 1; total=9
> 12.017: 644 read: 1; total=10
> 
> I tested this STC with differnt clocks, but it's important to
> use the same cloack for clock_gettime and timerfd_create.

Yes, that was careless of me.  I now get the same results as you.  I'll have to 
go back to the emacs sources and see what else might be different there.

Ken