NUMA functions for accessing replicated areas
Quoted 14 lines
Quoted 10 lines · Andrea Arcangeli
On Sat, Jan 19, 2002 at 11:25:17AM +1100, Keith Owens wrote:
The opaque void * spread across all the API looks rather scary. Furthmore I'm not convinced we need to pass any cookie to the api, all the calls knows the numadata info by the static status after boot.So I think something like this should be enough:
int numa_replicated(unsigned long address, int size); int numa_getarea(void *to, unsigned long from, int size); int numa_putarea(unsigned long to, void *from, int size);
Quoted 7 lines
That assumes that all replicated data is identical. It starts off that way but what prevents one set of replicated data being changed and not the others? I don't mind that assumption, it makes life easier for kdb, but I did not want to constrain NUMA implementations. However if everyone agrees that each instance of replcated data should always be identical then
numa_getarea()can read from any instance andnuma_putarea()writes to all instances, no need fornuma_replicate_loop.
Currently, all replicated data is identical. I can imagine a few cases where we might consider having different data, but nothing like that is currently planned. I doubt that any performance advantage of non-identical replicated data is worth the extra complexity.
There is one thing that occurred to me. Currently, on IA64, the replicated data is read-execute. The NUMA code known how to write it but I dont know if you want to teach kdb how to do it. It is easy to do on IA64. I dont know about other platforms (or even if it would apply).
TR0 is used to access the node local copy of kernel text
INSTRUCTION TRANSLATION REGISTERS
NODE 0, CPU 0
| VPN PPN PS MA ED AR PL D A P KEY RID |
| 0 | e002000000000000 0000000000000000 64M WB 1 1 0 0 1 1 000000 000007 |
NODE 1, CPU 0
| VPN PPN PS MA ED AR PL D A P KEY RID |
| 0 | e002000000000000 0000000204000000 64M WB 1 1 0 0 1 1 000000 000007 |
Quoted 17 lines
Quoted 5 lines
Futhmore it may be even better to drop
numa_replicatedcompletly and to default using numa_getarea/numa_putarea always, this should make kdb even cleaner. Implementation of getarea/putarea for non numa case will be a simple memcpy.If
numa_replicated()returns true then it is safe to use memcpy, ifnuma_replicated()is omitted then the get/put functions must validate the from address on get and the to address on put. kdb v2.1 relies on the MMU via__copy_to_user()to detect invalid user supplied addresses._______________________________________________
Discontig-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/discontig-devel
Signature · 3 lines
Thanks Jack Steiner (651-683-5302) (vnet 233-5302) [email protected]