Skip to content

Conversation

@mangod9
Copy link
Member

@mangod9 mangod9 commented Aug 28, 2020

Should resolve #41398. Will need to backport to .net 5.

@ghost
Copy link

ghost commented Aug 28, 2020

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

@mangod9 mangod9 requested review from Maoni0, janvorli and jkotas August 28, 2020 20:24
Copy link
Member

@janvorli janvorli left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

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

Thank you!

@jkotas
Copy link
Member

jkotas commented Aug 28, 2020

@mangod9 Could you please also apply @am11 's suggestion: #41398 (comment)

@mangod9
Copy link
Member Author

mangod9 commented Aug 28, 2020

wondering if we might need to special case arm32 too, since I am seeing arm build failures, its not quite apparent from the errors whether new code is causing it, but seems suspicious.

@jkotas
Copy link
Member

jkotas commented Aug 28, 2020

The ARM build errors are:

/__w/1/s/src/coreclr/src/pal/src/misc/sysinfo.cpp:578:12: error: no matching function for call to 'ReadMemoryValueFromFile'
        if(ReadMemoryValueFromFile("/sys/devices/system/cpu/cpu0/cache/index0/size", &size))
           ^~~~~~~~~~~~~~~~~~~~~~~
/__w/1/s/src/coreclr/src/pal/src/misc/sysinfo.cpp:514:1: note: candidate function not viable: no known conversion from 'size_t *' (aka 'unsigned int *') to 'uint64_t *' (aka 'unsigned long long *') for 2nd argument
ReadMemoryValueFromFile(const char* filename, uint64_t* val)
...

@mangod9
Copy link
Member Author

mangod9 commented Aug 28, 2020

Ah yes, I see them now in the raw build log. CI seems to suggest the native build was successful (the leg is green too), will follow up with Infra on this. Here are the final few lines from the build log

2020-08-28T21:42:45.5127898Z Repo successfully built.
2020-08-28T21:42:45.5129065Z Product binaries are available at /__w/1/s/artifacts/bin/coreclr/Linux.arm.Release
2020-08-28T21:42:45.5153650Z 

@jkotas
Copy link
Member

jkotas commented Aug 28, 2020

The build infra issue is #34496

@mangod9 mangod9 merged commit a3515ba into dotnet:master Aug 29, 2020
@mangod9 mangod9 deleted the alpine_cachesize branch August 29, 2020 05:17
@mangod9
Copy link
Member Author

mangod9 commented Aug 29, 2020

/backport to release/5.0

@github-actions
Copy link
Contributor

Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/229731217

@adamsitnik
Copy link
Member

Is there any way we could ensure that this problem never comes back? Like having a unit test that asserts that GetLogicalProcessorCacheSizeFromOS() returns more than zero? Or just a debug assert?

@mangod9
Copy link
Member Author

mangod9 commented Sep 1, 2020

@adamsitnik created #41708 for ensuring this doesnt regress.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Performance regression: 6x slower array allocation on Alpine

4 participants