Bug #16007: Process.clock_getres matches the clock in practice for Process::CLOCK_{PROCESS,THREAD}_CPUTIME_ID FAILED fails on armv7hl

• Status: Closed
• Assignee: Eregon (Benoit Daloze)
• Target version: -
• ruby -v: ruby 2.7.0dev (2019-07-15T10:39:47Z master 0c6c937904) [x86_64-linux]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN

[vo.x (Vit Ondruch)]

During build of Ruby 2.7.0 0c6c937904 on Fedora Rawhide, I observe following test failure on armv7hl (other arches are fine):

1)
Process.clock_getres matches the clock in practice for Process::CLOCK_PROCESS_CPUTIME_ID FAILED
Expected 10000
 not to equal 10000
/builddir/build/BUILD/ruby-2.7.0-0c6c937904/spec/ruby/core/process/clock_getres_spec.rb:30:in `block (4 levels) in <top (required)>'
/builddir/build/BUILD/ruby-2.7.0-0c6c937904/spec/ruby/core/process/clock_getres_spec.rb:4:in `<top (required)>'
2)
Process.clock_getres matches the clock in practice for Process::CLOCK_THREAD_CPUTIME_ID FAILED
Expected 10000
 not to equal 10000
/builddir/build/BUILD/ruby-2.7.0-0c6c937904/spec/ruby/core/process/clock_getres_spec.rb:30:in `block (4 levels) in <top (required)>'
/builddir/build/BUILD/ruby-2.7.0-0c6c937904/spec/ruby/core/process/clock_getres_spec.rb:4:in `<top (required)>'
Finished in 189.216527 seconds
3770 files, 30971 examples, 112151 expectations, 2 failures, 0 errors, 0 tagged

I did not observe such issue previously testing with d9f8b88b47

[ko1 (Koichi Sasada)]

We have no device to debug it.
Could you make a patch?

[naruse (Yui NARUSE)]

• Status changed from Open to Feedback

Patch is welcome

[vo.x (Vit Ondruch)]

It should be possible to get some hardware here:

https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

I am afraid I don't have any knowledge about Process::CLOCK_{PROCESS,THREAD}_CPUTIME_ID

[Eregon (Benoit Daloze)]

• Status changed from Feedback to Closed

Applied in changeset git|324dd9d01f0c97631a2588f63231bcb651844cca.

---

armv7l and armv7l are the same platform, generalize to armv7

[Bug #16007]

[Eregon (Benoit Daloze)]

• Assignee set to Eregon (Benoit Daloze)

I fixed the spec.
Those clocks were already excluded for armv7l but not armv7hl, so I generalized to armv7.

[vo.x (Vit Ondruch)]

• Status changed from Closed to Assigned

Thx.

However, I wonder if there is some explanation for disabling the test. I see a lot of comments such as # These clocks in practice on Linux do not seem to match their reported resolution. or # These clocks in practice on ARM on Linux do not seem to match their reported resolution. but that is strange. Why they should be? Is that known limitation of Linux or some HW? I would be interested to know.

The point is that I don't understand what would be the point of such API if the results can't be trusted ...

[Eregon (Benoit Daloze)]

vo.x (Vit Ondruch) wrote:

However, I wonder if there is some explanation for disabling the test. I see a lot of comments such as # These clocks in practice on Linux do not seem to match their reported resolution. or # These clocks in practice on ARM on Linux do not seem to match their reported resolution. but that is strange. Why they should be? Is that known limitation of Linux or some HW? I would be interested to know.

My understanding is those are all operating system (or maybe hardware) bugs.
It seems operating systems don't bother testing clock_getres() much, and as a result I would recommend to never use it.

Also see https://github.com/copiousfreetime/hitimes/pull/73#discussion_r287894886 for one usage I know of.

The point is that I don't understand what would be the point of such API if the results can't be trusted ...

Maybe we should remove Process.clock_getres() since it's so frequently inconsistent with clock_gettime()?

[jeremyevans0 (Jeremy Evans)]

• Status changed from Assigned to Closed