Improve support for RISC-V architecture on Linux

[facebook-github-bot]

Hi @GlassOfWhiskey!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[GlassOfWhiskey]

Hi, Any comment on this?

[appujee]

ping. any update on when this will land?

cc: @Maratyszcza

[appujee]

https://github.com/torvalds/linux/commit/16252e018a30486eedcfec81fc313445cac25bea maybe helpful in revising this patch.

[GlassOfWhiskey]

@malfet I've seen that a recent PR (#190) on RISC-V support has been merged into the main branch. However, I think this PR can still be useful for some reasons:

• It adds support for some additional features, like caches and uarchs;
• It allows to retrieve CPU information by parsing the /proc/cpuinfo output, as a baseline method;
• It disables the hwprobe path for kernels older than 6.4.0, which prevents the actual version of cpuinfo to compile on almost all current RISC-V systems on the market.

It is still not clear to me why @prashanthswami chose to open a sibling PR instead of converging the efforts on a single one. However, I tried to manually merge #190 into this PR, applying some minor modifications when deemed necessary. Please let me know what you think.

[malfet]

@GlassOfWhiskey can you please amend the title and expand description to nightlight what this PR is trying to accomplish.

[prashanthswami]

@GlassOfWhiskey - I sincerely apologize, this was poor GitHub practice on my part. I had written my PR a few months ago on an internal fork and needed it up streamed somewhat quickly, so I pushed it without analyzing the open PRs. When I looked at this issue last, it hadn't been active for a few months, so I was worried it would be inappropriate to ping here and ask for an accelerated landing, just to satisfy my own project timelines. In hindsight, I see that it would have been courteous to message here and coordinate, or CC you on the other PR. I'd like to make sure I don't do this again - should I CC you on any open PRs I have for RISC-V contributions to this repo?

[GlassOfWhiskey]

@GlassOfWhiskey - I sincerely apologize, this was poor GitHub practice on my part. I had written my PR a few months ago on an internal fork and needed it up streamed somewhat quickly, so I pushed it without analyzing the open PRs. When I looked at this issue last, it hadn't been active for a few months, so I was worried it would be inappropriate to ping here and ask for an accelerated landing, just to satisfy my own project timelines. In hindsight, I see that it would have been courteous to message here and coordinate, or CC you on the other PR. I'd like to make sure I don't do this again - should I CC you on any open PRs I have for RISC-V contributions to this repo?

@prashanthswami no problem, it was just a bit of work to merge all the things, but the important thing is to provide community with RISC-V support, no matter how or who :) I'll start addressing your comments. Since there is a lot of stuff, I'll probably do it incrementally, so that we can track progresses. Then we can squash all commits at the end.

As a general comment @prashanthswami @malfet: if you care so much about the code style and coherence, why don't you or someone in the maintainers team put a .clang-format file or something equivalent in the repo? So that contributors can automatically format the code before submitting and you can integrate style adherence directly in the CI pipeline?

[prashanthswami]

In regards to style-adherence, I'll defer to @malfet here, I'm only along for the ride :) my format comments were largely just parroting earlier comments Marat / Nikita gave me. Supportive though of the idea, anything that lets my IDE auto-switch to the right format is desirable. Does PyTorch have top-level guidance about what is considered proper code format?