Re: (ia32) vmalloc/ioremap

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Fri, 12 Feb 1999 07:00:09 +0100 (CET)


>
> Hi,
>
> Has anyone noticed that vmalloc()/ioremap() seem to be
> overly complicated procedures? Basically, vmalloc_area_pages()/
> remap_area_pages() might be getting called on an until now unused
> kernel virtual address, for which a kernel page table needs to be
> allocated. set_pgdir() takes care of this by:
> 1. updating the page directory of each running task.
> 2. updating the cached free page directories on each cpu.
>
> It seems to me that we could do away with the complexity of set_pgdir
> if we were to allocate a few kernel page tables at kernel startup
> time, have the kernel page directory entries for swapper_pg_dir
> mapping the vmalloc area point to these kernel page tables and have
> those be copied to every new page directory in the system. Of course,
> the whole vmalloc area (VMALLOC_START .. VMALLOC_END) would take too
> many kernel page tables probably, so we would need to resize the
> vmalloc area to something more easily handled, say 32M on a 64M
> system (or any other heuristic), which requires 8 kernel page table
> pages.

Huh? There are several places which need larger vmalloc area, so even if
you'd preallocated some vmalloc pgdirs, you could easily run out of them and
would need exactly the same set_pgdir() to allocate further pgdirs.
If you preallocate 8 pgdirs, then the current scheme will do set_pgdir 8
times... What's the problem? It is usually not speed critical.
Not to say that with nice MMU you don't have to suffer from such complexity
at all.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.1 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/