IRC channel logs
2023-08-16.log
back to list of logs
<apteryx>awesome! well done to everyone involved <damo22>solid_black: do you know if gnumach uses %fs or %gs <damo22>i want to claim one of these for storing a pointer to per-cpu stuff <solid_black>damo22: afaik it doesn't use either currently for its own purposes, it only tracks the userspace's values <damo22>then we can store the apic id in memory and read it very quickly <damo22>reading it from lapic is 8microseconds and cpuid way is 60 nanoseconds <solid_black>the thing is, you kind of want %gs to point it something, it's inconvenient to make it store an int <solid_black>so you'd allocate some per-cpu data block there, like userland's tls, and make it point there <damo22>i guess it can be allocated with kalloc? <solid_black>you could just store an integer, but my point is instead of using an integer and then indexing into some global arrays with that integer, it's better to store everything in per-cpu blocks in the first place <solid_black>for instance currently current_thread() is defined to active_threads[cpu_number()] <solid_black>but instead you'd do struct percpu { ...; thread active_thread; } <damo22>that would speed up a lot wouldnt it?" <solid_black>maybe? i don't know, you're the one who's done the profiling :) <solid_black>so perhaps in the end you wouldn't need the number at all <solid_black>and actually, Mach already has that struct percpu, and it's called struct processor (see kern/processor.h) <solid_black>so make %gs point at struct processor for the current cpu <damo22>but it doesnt have active_threads[] <solid_black>there's struct thread next_thread, not sure if that's the same thing <damo22>i can put processor_t processor in the percpu thing <damo22>because there are things i want to store that are not in processor_t <solid_black>so %gs is a segment register, you can't quite use it directly, especially not on x86_64 <solid_black>we should add a bunch of macros/helpers for this like glibc does, but basically gcc supports a separate __seg_gs address space <damo22>do i need to use a fixed address in the ld script? <solid_black>and mach already does 'struct processor processor_array[NCPUS];' <damo22>i think the most expensive part is continually looking up the cpuid <damo22>to find the right index into all the arrays <damo22>theyre all macros that expand to cpu_number() <solid_black>it cannot cache the value because there's nowhere for it to cache it in <damo22>yes, but i mean if it reuses the same cpu_number in multiple calls in the same function <solid_black>but still I'd expect cpu_number to be called many times during a syscall, across different functions <solid_black>but yeah really gs and percpu data would be much better <damo22>how do you make it arch agnostic <damo22>do all cpus provide a reg you can use for that? <solid_black>just declare a function like processor_t current_procssor() <solid_black>but yes, all archs have to support somthing like that <damo22>i dont want to implement code that has to be totally refactored just to support a new arch <solid_black>well the specific mechanism how per-cpu data is found is surely arch-specific, there's no way around that <damo22>yes but we need some kind of interface that allows arch-specific code to override the method <solid_black>I'm saying, a current_procssor() function that is implemented in arch-specific code that returns this pointer <solid_black>so on x86 (both i386 and x86_64) it'd just be processor_t current_processor(void) { return *(__seg_gs processor_t *) 0; } <damo22>are you sure? in the kernel dont we have to implement %gs stuff in asm <solid_black>or we could do it in asm, yeah, but __seg_gs also works <solid_black>as long as you don't assign through it, 'cause then gcc miscompiles <solid_black>you can only load a pointer into gs_base, and then you can do %gs:offset <damo22>i think youre reading the asm wrong <solid_black>he's storing the address itself in %fs, and then adding struct offset to the value of %fs, no? <solid_black>are all these per-cpu variables set to low addresses in the linker script?