Project

General

Profile

Bug #16007

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

Added by vo.x (Vit Ondruch) 3 months ago. Updated 22 days ago.

Status:
Assigned
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.7.0dev (2019-07-15T10:39:47Z master 0c6c937904) [x86_64-linux]
[ruby-core:93810]

Description

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

Associated revisions

Revision 324dd9d0
Added by Eregon (Benoit Daloze) about 1 month ago

armv7l and armv7l are the same platform, generalize to armv7

[Bug #16007]

History

Updated by ko1 (Koichi Sasada) about 1 month ago

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

Updated by naruse (Yui NARUSE) about 1 month ago

  • Status changed from Open to Feedback

Patch is welcome

Updated by vo.x (Vit Ondruch) about 1 month ago

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

#4

Updated by Eregon (Benoit Daloze) about 1 month ago

  • Status changed from Feedback to Closed

Applied in changeset git|324dd9d01f0c97631a2588f63231bcb651844cca.


armv7l and armv7l are the same platform, generalize to armv7

[Bug #16007]

Updated by Eregon (Benoit Daloze) about 1 month ago

  • 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.

Updated by vo.x (Vit Ondruch) about 1 month ago

  • 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 ...

Updated by Eregon (Benoit Daloze) 22 days ago

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()?

Also available in: Atom PDF