Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for s390x cpu frequency #728

Closed
wants to merge 1 commit into from

Conversation

Sidong-Wei
Copy link

As could be seen from this issue, the unit test SysinfoTest.NominalCPUFrequency has always been failing on s390x machines. The reason for the failure is because there is no mechanism in abseil code to retrieve CPU time and frequency for s390x machines. I am adding the methods for s390x by referencing a similar method committed to another project, see here.

Copy link
Member

@derekmauro derekmauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you trying to solve some other problem besides a failing unit test? The failing unit test is for a method that not called by Abseil code at all, so it shouldn't be an issue that needs fixing.

@@ -81,7 +81,7 @@
// This macro can be used to test if UnscaledCycleClock::Frequency()
// is NominalCPUFrequency() on a particular platform.
#if (defined(__i386__) || defined(__x86_64__) || \
defined(_M_IX86) || defined(_M_X64))
defined(_M_IX86) || defined(_M_X64)) || defined(__s390x__)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/mYYcbXg0lGY makes me think that the counter retreived by the stck instruction is a clock, but not one that runs at the CPU frequency, since it seems constant across chips. Can you point me to documentation that shows otherwise?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the notes. Honestly speaking, I'm not very familiar with instruction set or cpu counter, so I guess what you are suggesting is that stck does not return the correct cpu time so the frequency calculated based on this will not be accurate, am I understanding it correctly? If this is the case, could you please give me a hint of what counter do we need to retrieve here so that I could look into it further? Thank you.

@Sidong-Wei
Copy link
Author

I am also not sure how likely this API will be used by s390x users, but the reason I would like to fix this is that Tensorflow uses this API in its code, see here, and that also leads to some test case failures with Tensorflow.

@derekmauro
Copy link
Member

TensorFlow should not be doing that.

From https://abseil.io/about/compatibility:

Do not depend upon internal details. This should go without saying: if something is in a namespace or filename/path that includes the word “internal”, you are not allowed to depend upon it. It’s an implementation detail. You cannot friend it, you cannot include it, you cannot mention it or refer to it in any way.

@Sidong-Wei
Copy link
Author

Thanks for pointing out that, I did feel a little bit strange when seeing them using this API rather than another Tensorflow-native API to retrieve CPU frequency. I may raise an issue in the Tensorflow community about this.

As for the fix itself, I think I will still look into it a little bit to see if I could fix it. If it is too much trouble, I guess I will then close this PR since it is not a critical bug as you mentioned. Will that be okay if I leave it open now?

@rogeeff
Copy link
Contributor

rogeeff commented Jul 8, 2020

Do we need to keep this PR in open state?

@Sidong-Wei
Copy link
Author

Hi, I have raised the issue with Tensorflow and they have not responded yet, so I will follow up on it. Currently, I think it may not worth investing more time in fixing the cpu frequency issue since it is not actually used (or not supposed to be used) anywhere, so I will close this PR for now and I will consider reopening it if things have changed. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants