cache cpu info in a file at boot.

[bunnitha]

Instrumented cpuinfo to read the populated cpu info data from cpuid.info file during initialization.
Consumers of the library or OEMs can trigger a oneshot service - cpuinfo-svc - during device boot to link libcpuinfo and
dump all cpu info related to processor, model, arch and isa capabilities into cpuid.info file.
This arrangement will limit cpuid() intrinsic calls (which causes VMX events and performance overhead) to only once during init of libcpuinfo at boot by cpuinfo-svc.

Its little tricky to count the exact number of VM-Exits caused by CPUID calls.
For this effect, we have written a script to run an Android (dummy) service
that loads libcpuinfo - first in original version and next in modified version.
libcpuinfo makes around 4 __cpuid() calls on each initialization.
So, to amplify the effect, we have run the dummy service 1000 times and timed the total
execution (4000 __cpuid() calls and 8000 VMX events) in nano second precision.
This test shows that there is a reduction of approx. 0.6% in time to execute libcpuinfo.

Also, we attempted to record the KVM event statistics using perf tool.
Perf records the stats during the execution of same script.
The data shows that approx. 20,000 kvm_cpuid events reduced in modified libcpuinfo calls.
We cannot assume that all the CPUID calls are contributed by our script.
We are only making a safe assumption that the proportional reduction is affected
by the modification we did. We had made all efforts to keep the test conditions
similar in both cases.

Please find attached the excel sheet containing the test data.
libcpuinfo_enhancement_test_data.xlsx

[bunnitha]

Hi, requesting concerned moderator to take a look at this proposal and review the patch.
Intel wants Pytorch to adopt this solution so that it can later land in Chrome ARCVM tree.

[digantdesai]

Thank you for your contribution.

(1) tlb refactor should be in a different commit
(2) please add some tests for cpuid features
(3) update PR summary for performance data and rationale for Android vm-exit overhead reduction.

[bunnitha]

separated tlb refactor codes and cpu info caching.

[digantdesai]

Hello, apologies for a delay, can you help me understand,

(1) why does it have to be __ANDROID__ specific. And Why can't a Linux user use cpuinfo-svc?
(1.1) Does it have to be x86 specific? We don't have to use it for other ISAs, I don't have a too strong preference here.
(2) why a user facing "app" is in the src/x86/linux/ vs cpuinfo/tools?

[bunnitha]

Thank you @digantdesai for your review.

Answer to (1) and (2):
The solution can be generic.
We have had it devised for ARCVM (Virtualized Android) on CrOS.
The deployment and validation have only been done on Android in x86 target (others are out of our scope).
To make sure the rest of the world don't break, we applied the ANDROID restriction.

[digantdesai]

(2) why a user facing "app" is in the src/x86/linux/ vs cpuinfo/tools?
I am ok if you restrict caching to android + x86, but please move the "app" out of the src dir.

[bunnitha]

(2) why a user facing "app" is in the src/x86/linux/ vs cpuinfo/tools?
I am ok if you restrict caching to android + x86, but please move the "app" out of the src dir.

Agreed!
As suggested, app moved into tools/ folder

[digantdesai]

I think we are getting pretty close. Left some minor comments. Thanks!

[digantdesai]

PR LGTM. Left a comment about validation after loading from the file.
Please also check and make sure the CI is green. Thanks.

[bunnitha]

0001-Cache-cpu-info-in-a-file-at-boot.patch
0001-Trigger-cpuinfo-svc-at-boot.patch
Complete patch to implement the solution in Android platform.