[haiku-development] Re: RFC: Removing B_MAX_CPU_NUM and reworking system_info
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 02 Dec 2013 16:49:58 +0100
On 12/01/2013 10:00 PM, Pawel Dziepak wrote:
It's high time we got rid of our 8 CPU limit.
Yes, please!
The above, should deal with the legacy binaries. New API has to be
created to allow programs to get system information in a more future
proof way. Here is what I propose:
typedef struct {
bigtime_t boot_time;
int32 cpu_count;
int32 {max,used}_pages;
int32 cached_pages;
int32 ignored_pages;
int32 page_faults;
int32 {max,used}_sems;
int32 {max,used}_ports;
int32 {max,used}_threads;
int32 {max,used}_teams;
char kernel_name[B_FILE_NAME_LENGTH];
char kernel_build_date[B_OS_NAME_LENGTH];
char kernel_build_time[B_OS_NAME_LENGTH];
int64 kernel_version;
int32 abi;
} system_statistics;
The pages related fields should be 64 bit to be future proof. And I'd
also make all fields that can't have negative values unsigned.
typedef struct {
bigtime_t active_time;
} cpu_statistics;
Topology and current state info could be added. If easily available, the
current load factor as well.
#define get_system_statistics(stat) _get_system_statistics(stat, sizeof(*stat))
status_t _get_system_statistics(system_statistics* stat, size_t size);
#define get_cpu_statistics(firstCPU, cpuCount, stat)
_get_cpu_statistics(firstCPU, cpuCount, stat, sizeof(*stat))
status_t _get_system_statistics(int32 firstCPU, int32 cpuCount,
cpu_statistics* stat, size_t elementSize);
system_statistics is basically current system_info with both
problematic and obsolete fileds removed. get_cpu_statistics() allow to
obtain statistics of several logical processors using just one system
call. Macros ensure that both system_statistics and cpu_statistics can
be extended without breaking ABI (_get_cpu_statistics() expects stat
to point to a buffer of size cpuCount * elementSize).
The macros won't be necessary. The same can be achieved with ELF symbol
versioning (also allowing reordering of fields). In fact we wouldn't
even need to introduce new structure/function names, but could just
continue to use system_info/cpu_info/get_system_info(). The advantage is
that in many use cases of get_system_info() the code wouldn't even need
to be adjusted (the change of signedness of most fields may cause some
warnings, though).
There is also a matter of detecting CPU features. At least on x86[_64]
that does not require kernel privileges. (Actually, obtaining the
system statistics could be done also without syscall if the necessary
information is published using commpage. That's an implementation
detail, though.) That's why I think that even if we want to provide an
interface for that it could be implemented completely in libroot. Such
information as CPU model and features should undoubtedly be obtained
on per CPU basis because of heterogeneous architectures like for
example ARM big.LITTLE. The interface for that should be architecture
independent and much more general than current get_cpuid().
Agreed.
CU, Ingo
Other related posts:
