Hi, Does the kernel code run through the MMU and page tables?
My expectation was No as among others there is no need to relocate dynamically the kernel code and associated data if paging for instance is used. The kernel code consists of a set of pre known processes that are loaded in a pre-set area in the memory. If the code runs through MMU and page tables, this will slow down the kernel code execution.
I read that in the coming 64-bit machine, inverted page table will be used to do the translation. If the kernel code is running through the MMU and inverted page table, do the systems allocate a single "inverted page table" for both user processes and kernel processes or instead one for each type
for x86, yes when the protected mode is set, the MMU works. and all addresses are required to be translated into physical address, even the kernel. Read System.map and the link script in arch/i386/kernel/, the answer is there.
> Hi, > Does the kernel code run through the MMU and page tables?
> My expectation was No as among others there is no need to relocate > dynamically the kernel code and associated data if paging for instance > is used. The kernel code consists of a set of pre known processes that > are loaded in a pre-set area in the memory. If the code runs through > MMU and page tables, this will slow down the kernel code execution.
> I read that in the coming 64-bit machine, inverted page table will be > used to do the translation. If > the kernel code is running through the MMU and inverted page table, do > the systems allocate a single "inverted page table" for both user > processes and kernel processes or instead one for each type
xu_feng...@yahoo.com wrote: > Hi, > Does the kernel code run through the MMU and page tables?
Yes, on simple architectures that don't implement kernel segments. On some architectures like i386, virtual memory is an all-or-nothing proposition. Either all addresses generated by the CPU are subject to virtual address translation through the TLB and page tables, or all addresses are just physical.
On some architectures, the address space can be partitioned. A given slice may be subject to paging, and other slices to some straightforward displacement to their corresponding physical range.
> My expectation was No as among others there is no need to relocate > dynamically the kernel code and associated data if paging for instance > is used.
The kernel works with virtual addresses transparently. A given pointer variable could for example point to user-space virtual memory, kernel virtual memory from vmalloc, a static object, a location on a kernel stack, or to memory from kmalloc. They all work uniformly.
On the i386, they all go through the MMU. On a different architecture like MIPS, the translation of the address by the hardware, and even the semantics of the access, depend on which segment of the address space it falls into.
xu_feng...@yahoo.com wrote: > Hi, > Does the kernel code run through the MMU and page tables?
> My expectation was No as among others there is no need to relocate > dynamically the kernel code and associated data if paging for instance > is used. The kernel code consists of a set of pre known processes that > are loaded in a pre-set area in the memory. If the code runs through > MMU and page tables, this will slow down the kernel code execution.
For one, this set can change over reboots. Secondly, even the kernel has varying requirements for data storage. Thirly, as Kaz has pointed out, on x86 its all-or-nothing. The speed penalty is not as high as you might expect, as not every access has to go through the tables. A "TLB" (Translation-Lookaside-Buffer) caches the most recently used address translations, so only the access to a new page will require walking through the tables.
-- Josef Möllers (Pinguinpfleger bei FSC) If failure had no penalty success would not be a prize -- T. Pratchett
>Does the kernel code run through the MMU and page tables?
>My expectation was No as among others there is no need to relocate >dynamically the kernel code and associated data if paging for instance >is used. The kernel code consists of a set of pre known processes that >are loaded in a pre-set area in the memory.
The kernel is not a static entity. Kernel modules and kernel memory come and go.
>If the code runs through MMU and page tables, this will slow down the >kernel code execution.
Nope. As Michael implied, it depends on the processor, but on every virtual memory processor I've ever used, ALL addresses are virtual addresses. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc.
xu_feng...@yahoo.com wrote: > Hi, > Does the kernel code run through the MMU and page tables?
> My expectation was No as among others there is no need to relocate > dynamically the kernel code and associated data if paging for instance > is used. The kernel code consists of a set of pre known processes that > are loaded in a pre-set area in the memory. If the code runs through > MMU and page tables, this will slow down the kernel code execution.
What about the fact the kernel is mapped in the adress space of processes, so that they can run in user mode and kernel mode?
ta...@lpthe.jussieu.fr (Michel Talon) wrote: >xu_feng...@yahoo.com wrote: >> Hi, >> Does the kernel code run through the MMU and page tables?
>> My expectation was No as among others there is no need to relocate >> dynamically the kernel code and associated data if paging for instance >> is used. The kernel code consists of a set of pre known processes that >> are loaded in a pre-set area in the memory. If the code runs through >> MMU and page tables, this will slow down the kernel code execution.
>What about the fact the kernel is mapped in the adress space of >processes, so that they can run in user mode and kernel mode?
That's an implementation detail. It isn't actually required for the Linux kernel. You could operate with separate address spaces, as long as there's a way to implement copy_from_user and copy_to_user. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc.
xu_feng...@yahoo.com wrote: > My expectation was No as among others there is no need to relocate > dynamically the kernel code and associated data if paging for instance > is used. The kernel code consists of a set of pre known processes that > are loaded in a pre-set area in the memory. If the code runs through > MMU and page tables, this will slow down the kernel code execution.
The last sentence is really not true. On modern processors, the MMU and page table implementations are heavily optimized and impose a negligible performance penalty.
Even cooler, the mappings for the kernel can be marked global. This marking will be carried into the caches, so that when a process switch occurs, those mappings are not expunged from the caches.
>> My expectation was No as among others there is no need to relocate >> dynamically the kernel code and associated data if paging for instance >> is used. The kernel code consists of a set of pre known processes that >> are loaded in a pre-set area in the memory. If the code runs through >> MMU and page tables, this will slow down the kernel code execution.
> The last sentence is really not true. On modern processors, the MMU and > page table implementations are heavily optimized and impose a > negligible performance penalty.
I think this is this video[1] where Singularity authors claim that turning on paging (perhaps combined with other "protection/mapping" features) has far from negligible impact on the system performance (i gather they use some x86 variant).
Don't think i ever encountered any study (with verifiable results) that could support either of those views.
[..snip..]
[1] Perhaps the one before this one... or after...
malc <m...@pulsesoft.com> writes: > "David Schwartz" <dav...@webmaster.com> writes: >> xu_feng...@yahoo.com wrote: >>> My expectation was No as among others there is no need to relocate >>> dynamically the kernel code and associated data if paging for instance >>> is used. The kernel code consists of a set of pre known processes that >>> are loaded in a pre-set area in the memory. If the code runs through >>> MMU and page tables, this will slow down the kernel code execution.
>> The last sentence is really not true. On modern processors, the MMU and >> page table implementations are heavily optimized and impose a >> negligible performance penalty.
> I think this is this video[1] where Singularity authors claim that > turning on paging (perhaps combined with other "protection/mapping" > features) has far from negligible impact on the system performance (i > gather they use some x86 variant).
If so, somebody should tactfully inform them that "getting baffled by one's own bullshit" is hardly a thing to be proud of and that page-based virtual memory implementation have been in use for at least 25 years now, and mostly on computers with less processing power than a second rate cellphone of today, meaning if they have managed to write a piece of software which cannot tolerate the overhead imposed by using a MMU, they should perhaps consider this a hopefully educating failed experiment.
|
