On 07/10/2012 10:29 AM, Rajendra Nayak wrote:
Hi Daniel,
On Friday 06 July 2012 04:28 PM, Daniel Lezcano wrote:
The main purpose of all these cleanup patches are to move out all non-data information from the cpuidle_state structure in order to add a new api which could be 'cpuidle_register_cpu_latency(int cpu, struct cpuidle_latencies latencies)'.
So are there any technical difficulties in adding such an api with the non-data information being part of cpuidle_state? Or its just that you think the already duplicated non-data information (per state) is going to be duplicated much more (per state per cpu) in most cases.
Yes, it is possible. I am already working on an alternate patchset I will post soon, but I don't like to add more things in a subsystem before cleaning up the code when it makes sense.
When I looked at the cpuidle code, I noticed this 'enter' field was used for the same function. With per cpu latency and using the cpuidle_state structure, that means duplication of this field. For an x86_64 architecture with 16 cores and 4 C-states, that is 512 bytes of memory instead of 8 bytes.
That is the same for example the 'disable' field which could be stored in the 'flags' field as a bit instead of the moving it to the 'stats' structure with "unsigned long long".
As the architectures tend to add more cores [1][2], that means more memory consumption. In a very near future, we will have 100 cores in a cpu. Assuming we have 4 C-states, that is 100 * 4 * 8 = 3200 bytes of memory used for a single function. IMHO, the kernel shouldn't assume the user must add more memory on the system.
Anyway, I will post a patchset to use the cpuidle_state per cpu.
Thanks -- Daniel
[1] http://www.engadget.com/2007/02/11/intel-demonstrates-80-core-processor/ [2] http://www.tilera.com/products/processors/TILE-Gx_Family