[ As a courtesy to new readers: TCB = "thread control block", the kernel data structure holding thread-specific data including the thread's stack. ]
"Adam 'WeirdArms' Wiggins" awiggins@cse.unsw.edu.au writes:
I was woundering why the TCB size in ix86 L4 is 1K, how much of the stack at the end of the TCB is actually used?
Very little: Most of the time, less than 150 bytes.
Could the TCB be reduced to 512K? If not why not?
^^^^ 512 bytes?
I think it could. L4/x86 has disabled hardware interrupts most of the time, so the theoretical maximal stack usage probably isn't much higher than the one we see, maybe 100 bytes more. I guess Jochen didn't know it was so little when he designed L4, and never changed it later.
In the Fiasco kernel, things are different: This kernel had been written in C++, and it may be interrupted at almost any time; handlers may interrupt each other and stack up on one thread's stack. That's why the theoretical maximal stack usage is much higher. Although I haven't computed it yet, I have estimated that a < 1K stack is too small for the current implementation. That's why Fiasco by default is configured to use 2-KByte TCBs.
Michael
On 6 Jan 1999, Michael Hohmuth wrote:
[ As a courtesy to new readers: TCB = "thread control block", the kernel data structure holding thread-specific data including the thread's stack. ]
"Adam 'WeirdArms' Wiggins" awiggins@cse.unsw.edu.au writes:
I was woundering why the TCB size in ix86 L4 is 1K, how much of the stack at the end of the TCB is actually used?
Very little: Most of the time, less than 150 bytes.
Could the TCB be reduced to 512K? If not why not?
^^^^ 512 bytes?
Yes sorry i ment that :)
I think it could. L4/x86 has disabled hardware interrupts most of the time, so the theoretical maximal stack usage probably isn't much higher than the one we see, maybe 100 bytes more. I guess Jochen didn't know it was so little when he designed L4, and never changed it later.
Actually Jochen posted me and its 512 as of version 3.
In the Fiasco kernel, things are different: This kernel had been written in C++, and it may be interrupted at almost any time; handlers may interrupt each other and stack up on one thread's stack. That's why the theoretical maximal stack usage is much higher. Although I haven't computed it yet, I have estimated that a < 1K stack is too small for the current implementation. That's why Fiasco by default is configured to use 2-KByte TCBs.
Question here. Is Jochen's L4 got higher interupt latencies then fiasco due to masking out interupts or is time in the kernel small enough for real time applications. My port is going to target real time applications. There are 2 interrupt exceptions IRQ (normal irq) and FIQ (fast irq). The only difference is FIQ are only masked when an FIQ exceptoin is generated or when you mask them out AND FIQ's bank more registers which means you have less to pop on the stack. Since the SA1100 interrupt controler lets you route interupts to either the exception i was just going to use IRQ for now and worry about FIQ when the implimentation was mature enough to worry.
BTW thanks for you time and enthusiasm it helps the motivation. I'm currently trying to do my memory layout and data structures. The only thing i've really left to work out in that is the mapping tree (waiting on working out the new mapping database) and how to allocate memory for page table entries which are 1k or 16k (aligned)
Cheers Adam
l4-hackers@os.inf.tu-dresden.de