Hi Joshua,
Am 01.03.2006 um 08:43 schrieb Joshua LeVasseur:
Hi Kay-Uwe,
Sorry about the slow response; super busy here.
Don't worry, I'm very glad to get such a detailed answer. Thanks, this was helping to understand things better.
You recommend "enabling virtual addressing immediatly". Did I understand it right, that you use virtual memory in kernel mode? Is this only for protection or means this, the kernel memory is vitual? There are other kernels using virtual memory in kernel mode?
Probably all kernels use virtual addressing in kernel mode. If I remember correctly, the processor executes with degraded performance in physical mode, but maybe I'm thinking about other processor architectures.
I take a deeper look in the darwin kernel sources and yes, it seems that they try to get the MMU running as fast as possible.
We need virtual addressing for Pistachio, since the kernel algorithms rely on the virtual addresses. For example, the TCBs are managed via virtual addresses, to help reduce the number of TCB validity checks on the fast path, and for fast TCB lookup. Other features requiring virtual addressing: string copy (temporary mapping), UTCBs (contiguous area).
My design doesn't have a kernel section in the tasks address space (on 32 bit machines a task is 4GB). I agonise to solve some of the problems with this design. In the case StringItems used to send Msg's from one space to another (means copy the information in the kernel) the message buffer on both sides can scattered and located across page bounderies. Handling this seems easier if the kernel has the same view to memory and pionters to memory regions (buffers) but this destroy my approach of lockfreeness, because the String Buffers in different tasks can by overlap or locate at the same virtual adress. (The sendphase of StringItems should by interruptable and at any time it should by possible to handle as much as possible StrinItem sends in the same time.) Handling this in kernel with the view of real memory avoid overlapping buffer regions from different threads. Do you see the issue like I and is there a solution I didn't see?
The solution is to invalidate the string copy mapping when the thread is preempted. When the thread is resumed, you'll get a page fault on the string copy, and then you restore the mapping area. PowerPC's segments are perfect for solving this problem, because of the address space IDs: you dedicate one segment to string copy; you copy the segment of the destination thread's target area into the dedicated segment; and then you can copy. When preempting, and when finished, you invalidate the dedicated copy segment.
My biggest mistake in thinking about the kernel in virtual mode was, to see the kernel as a unchangeable adress space. But the kernel is more an extension of a task and I can map both segments (source and destination) in the kernels adress space and if I switch the thread the mapping is changed (switched) also. This seems to work (theoretical, programming need more time). So it is no more than change the PPC Segment-Registers by thread switches.
As I see on the homepage, the kernel runs on a G3 (aka PPC750). So you use the normal hardware table search?
Yes, I use the hardware's hashed page table. Since the hashed page table is limited in size, I also maintain a master copy of the information in a set of forward-mapped page tables. Perhaps the forward-mapped page tables are unnecessary in PowerPC; I need them in Pistachio to be compatible with the architecture-neutral code (mapping database).
Regards, Josh
Thanks for the explanation
Regards
Kay-Uwe