This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Eric W. Biederman wrote: > Ulrich what would be interesting besides the possibility of having > multiple cpus? What is needed for various things like memory handling etc is all topology information. Somebody might remember the numa library proposal I had in April 2004 which was cast aside because people were only looking for a "quick fix". Well, the problem still isn't solved. IMO the vdso should export information about: - processors and their relationship (hyperthreads, cores) - the CPU caches and how they relate to the cores (e.g., dual core with shared L2) - local main memory for each processor - relative costs of the memory access of the various memory regions (for numa local memory to a node, intra-node costs) - ideally, relative costs main memory and CPU caches All this information can be steadily updated by the kernel as new CPUs/memory get added/removed. The vdso should have functions to access this information. It's easy enough to make this access race free. I guess I should try to come up with a representation for this knowledge. Collecting the information (except the costs) should be easy. Determining the costs also shouldn't be that hard but it can be very useful. Some of this information could be determined at userlevel but you really don't want every process to compute all this from scratch. And stored data in a file is stale if the system changes. -- â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |