Hi everyone,
I've been working on my own os (for x86) for quite a while now and I'm in the middle of implementing memory management. I've seen that most OS's seem to map the kernel in each process' address space, either at the start or at the end. Since it is possible to switch tasks on interupt I was wondering if it wouldn't be better to service all interrupt in a kernel task, in it's own address space? Wouldn't this also make locking easy? Why isn't this done? Or is the cost of switching tasks on each interupt too high?
thanks,
- Grinny -
To the systems programmer, users and applications serve only to provide a test load.
Where to map the kernel
-
rexlunae
- Member
- Posts: 134
- Joined: Sun Oct 24, 2004 11:00 pm
- Location: North Dakota, where the buffalo roam
Re: Where to map the kernel
Yes, it is probably possible to have the kernel do most of its work in a separate memory space, but there are several good reasons not to do it.
1. Doing a full context switch for each interrupt requires invalidating most of the cache, so in cases where the kernel runs and then returns to the process which was running, there would likely be a very negative impact upon performance. In addition, if you are servicing a system call, it is very useful to have access to the memory of the process that made the call without having to map it back in.
2. Even under this system, you still need at least 4 kernel structures to be mapped into memory, the GDT, the IDT, and 2 TSSes, in which case it is probably not significantly easier to do things this way.
3. Because it relies on segmentation features specific to the 32-bit x86 processors, the portability of this approach would be severly limited. For instance, I don't believe this would even work on the x86-64 systems because of reduced reliance on and support for segmentation.
Generally, I have avoided using segmentation and TSSes to handle switching tasks, and I have found that the way I switch tasks is both more portable and easier.
Oh, and about locking...
I don't think there is really an implication here for locking. Locking is not hard on uniprocessor systems. It's just when you start supporting multiprocessing that it becomes more difficult. I don't really see an advantage in putting the kernel in a separate address space for locking. Care to elaborate?
1. Doing a full context switch for each interrupt requires invalidating most of the cache, so in cases where the kernel runs and then returns to the process which was running, there would likely be a very negative impact upon performance. In addition, if you are servicing a system call, it is very useful to have access to the memory of the process that made the call without having to map it back in.
2. Even under this system, you still need at least 4 kernel structures to be mapped into memory, the GDT, the IDT, and 2 TSSes, in which case it is probably not significantly easier to do things this way.
3. Because it relies on segmentation features specific to the 32-bit x86 processors, the portability of this approach would be severly limited. For instance, I don't believe this would even work on the x86-64 systems because of reduced reliance on and support for segmentation.
Generally, I have avoided using segmentation and TSSes to handle switching tasks, and I have found that the way I switch tasks is both more portable and easier.
Oh, and about locking...
I don't think there is really an implication here for locking. Locking is not hard on uniprocessor systems. It's just when you start supporting multiprocessing that it becomes more difficult. I don't really see an advantage in putting the kernel in a separate address space for locking. Care to elaborate?
Last edited by rexlunae on Sun Jan 23, 2005 12:00 am, edited 1 time in total.
Re: Where to map the kernel
i agree:
the task switch is VERY expensive since ALL TLBs will be invalidated (actually this will raise the cost of task switch since you no longer have GLOBAL tables)
plus this requires a task gate to handle ints,IRQs,and exceptions and x86-64 doesnt permit task gates (just looked it up this morning)
further this means all syscalls would also require a task switch and this happens frequently so having it within the same address space makes it much cheaper plus MOST of the kernel IS preemptable
the task switch is VERY expensive since ALL TLBs will be invalidated (actually this will raise the cost of task switch since you no longer have GLOBAL tables)
plus this requires a task gate to handle ints,IRQs,and exceptions and x86-64 doesnt permit task gates (just looked it up this morning)
further this means all syscalls would also require a task switch and this happens frequently so having it within the same address space makes it much cheaper plus MOST of the kernel IS preemptable
Re: Where to map the kernel
Thank you for your (fast) response,
I think your right and I'll map my kernel into the user processes. But now I'm wondering what's better, in high memory or in low memory, or doesn't this make any difference?
- Grinny -
If God had a beard, he'd be a UNIX programmer.
I think your right and I'll map my kernel into the user processes. But now I'm wondering what's better, in high memory or in low memory, or doesn't this make any difference?
You're right, that does sound silly, but it was pretty late in Holland when I wrote that.Wouldn't this also make locking easy?
- Grinny -
If God had a beard, he'd be a UNIX programmer.
Re: Where to map the kernel
most people (and both win&linux afaik) map kernel into upper portion of mem
this makes v86 mode much easier if you need it and it also makes it easier to return to rm (if you need to)
you can do it either way but for me it just makes more sense to map kernel high (but then again my brain generally works different than most peoples)
i'm using the 50/50 split since that is easy to implement and simplifies porting to x86-64 where mem has to be sign-extended anyway:this allows me to keep the memory gap(non-implemented address space) between the kernel and user space
this makes v86 mode much easier if you need it and it also makes it easier to return to rm (if you need to)
you can do it either way but for me it just makes more sense to map kernel high (but then again my brain generally works different than most peoples)
i'm using the 50/50 split since that is easy to implement and simplifies porting to x86-64 where mem has to be sign-extended anyway:this allows me to keep the memory gap(non-implemented address space) between the kernel and user space