common: Add rdtsc() support for s390x

[nealef]

Cycles: Add rdtsc() for s390x

z Systems (aka s390/s390x) supports a time-of-day clock of 64-bits.

Fixes: #39491

Signed-off-by: Neale Ferguson neale@sinenomine.net

• References tracker ticket
• Updates documentation if necessary
• Includes tests for new functionality or reproducer for bug

[gregsfortytwo]

Thanks for your contribution!

For us to merge this PR we need your Signed-off-By statement on all commits to indicate proper licensing: https://github.com/ceph/ceph/blob/master/SubmittingPatches.rst#signing-contributions

Can you please also rebase it so the PR just adds your commit and not the several merges back and forth? :)

[nealef]

I hope I got it right this time.

[gregsfortytwo]

@smithfarm I think you're the last one to do anything with s390, care to comment?

[tchaikov]

@nealef could you reference the tracker ticket like

Fixes: http://tracker.ceph.com/issues/39491

as in future, your comment would be connected to a PR with the same id.

also you might want to quote your email address with <>, like

Signed-off-by: Neale Ferguson <neale@sinenomine.net>

.

[smithfarm]

@smithfarm I think you're the last one to do anything with s390, care to comment?

The only thing I can do is test whether it breaks the s390x build. Unfortunately, right now I can't do even that because the s390x build is already broken on tip of master branch - tracked at http://tracker.ceph.com/issues/39611 (any and all help fixing that would be appreciated!)

[nealef]

I can look at those issues. I was breaking with the fcontext stuff due to boost context not having s390x support for make_fcontext/jump_fcontext/ontop_fcontext. I have managed to provide this function within the last hour. I haven't seen the string problem you've seen. Does it need to build with the devtoolset-7 suite?

[smithfarm]

@nealef Thanks! The build I'm referring to here is the RPM build, i.e. from the spec file.

The build referred to in that issue is on openSUSE Tumbleweed, but in general to reproduce the build failure you would need to run make-dist to produce a tarball and spec file, and then use rpmbuild to try to build the ceph RPMs from that tarball and spec file...

Alternatively, and perhaps simpler, you could look at the full build log and reproduce the cmake, make etc. commands that it uses to do the build: https://build.opensuse.org/public/build/filesystems:ceph:octopus:upstream/openSUSE_Tumbleweed_s390x/s390x/ceph/_log

[smithfarm]

@nealef Also, you can run ./install-deps.sh in the top-level directory of the git clone to install all build the dependencies in your build environment.

The full build log above shows all the packages that get installed for the Tumbleweed build, but for RHEL/CentOS those will obviously be different.

[nealef]

I am building ceph-2:14.2.0 rpm that comes with CentOS in their cloud repo and uses devtoolset-7 as it needs some features of gcc-c++ that aren’t available in the 4.8 packages. I’ll try and take a look later today as I am about to incorporate my boost changes into that build. From: Nathan Cutler <notifications@github.com> Reply-To: ceph/ceph <reply@reply.github.com> Date: Tuesday, May 7, 2019 at 13:14 To: ceph/ceph <ceph@noreply.github.com> Cc: Neale Ferguson <neale@sinenomine.net>, Mention <mention@noreply.github.com> Subject: Re: [ceph/ceph] common: Add rdtsc() support for s390x (#27797) @nealef<https://github.com/nealef> Thanks! The build I'm referring to here is the RPM build, i.e. from the spec file. The build referred to in that issue is on openSUSE Tumbleweed, but in general to reproduce the build failure you would need to run make-dist to produce a tarball and spec file, and then use rpmbuild to try to build the ceph RPMs from that tarball and spec file... Alternatively, and perhaps simpler, you could look at the full build log and reproduce the cmake, make etc. commands that it uses to do the build: https://build.opensuse.org/public/build/filesystems:ceph🐙upstream/openSUSE_Tumbleweed_s390x/s390x/ceph/_log<https://build.opensuse.org/public/build/filesystems:ceph:octopus:upstream/openSUSE_Tumbleweed_s390x/s390x/ceph/_log> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#27797 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AACLN6VLA5MW552RNUFH7DDPUG2INANCNFSM4HIQ5TCA>.

[nealef]

I am getting this when I go to the build log: package build was not possible: no compliant workers (constraints mismatch hint: hardware:memory) Please adapt your constraints.

[tchaikov]

@smithfarm as http://tracker.ceph.com/issues/39611 has been addressed, could you help verify that this change builds?

[stale]

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

[nealef]

Is there anything you need from me to help this progress?

[cbodley]

I was breaking with the fcontext stuff due to boost context not having s390x support for make_fcontext/jump_fcontext/ontop_fcontext. I have managed to provide this function within the last hour.

do you have patches working for boost context on s390x? it would be great to get those upstream - you might chime in on boostorg/context#111

[nealef]

Dan Horvak of RedHat has an intern working on this. I will wait until I see what they’ve come up with so I don’t confuse the issue with multiple versions of code.

[tchaikov]

thanks Neale ! closed in favor of #30874 .