how has set_pgdir been replaced in 2.4.x

Hello,

In the 2.2.x Linux kernel there used to be a function set_pgdir(), in charge of keeping all page global directories consistent. I.e. when modifying the kernel page tables (e.g. in vmalloc, or ioremap), set_pgdir() was called, to update the corresponding entry in any processes global page directory, as well as in the cached global page directories.

I noticed that in the 2.4.x Linux kernel the function set_pgdir() has gone (at least for most platforms). When looking at code that modifies kernel page tables (e.g. vmalloc_area_pages) I could not figure out, how the page global directories are kept consistent. It looks to me as if
global page directory entries were modified in one global page directory (the swapper_pg_dir) only. If this is the case, I wonder how the modifications are 'propagated' into all the other global page directories (I think they *must* at one moment be copied into all other global page directories, in order to make the new memory mapping visible in all process contexts).

I thought that maybe one global page directory was used for all processes, but than I wonder how the user space mappings in the beginning of the virtual address space (which are process specific) can be handled.

Please put me on cc: in your reply, since I am not subscribed to the list.

thank you in advance, regards
Martin

--

Supercomputing System AG          email: [email protected]
Martin Maletinsky                 phone: +41 (0)1 445 16 05
Technoparkstrasse 1               fax:   +41 (0)1 445 16 10

CH-8005 Zurich

--

Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

Hi,

They are now faulted on demand for vmalloc. The cost of manually updating all the pgds for every vmalloc is just too expensive if you've got tens of thousands of threads in the system.

Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

Hi,

Is there an implication on drivers, e.g. not accessing vmalloc'd memory from within a page fault handler? A page fault from a page fault handler is quite ugly...

Best regards, Martin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

Hi,

arch/i386/mm/fault.c is where the magic happens. The vmalloc fault path is really, really careful not to access any potentially volatile data, so it is supposed to be safe for use even inside traps and interrupts.

There _is_ one place where it can break down: if you have a driver which walks page tables manually after a vmalloc, expecting to translate virtual addresses into physical ones before the VA has been faulted in. Other than that, it should be safe.

Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/