Re: [PATCH] report user-readable fixmap area in /proc/PID/maps

[Linus Torvalds]

On Sun, 12 Oct 2003, Roland McGrath wrote:
> 
> I always assumed that people (i.e. Linus) wouldn't like it because of
> the overhead in memory and setup time for an extra vma that is identical
> in every process.  Given the constraint that the fixmap area is the last
> thing in the address space, I imagine that can be mitigated by some
> magic using a single shared fixmap_vma at the end of everybody's chain.

That would be a nice trick and works fine for the regular sorted list, but
it would be nasty for the rb-tree handling.

If you really want /proc/PID/maps to look right, add a new vm_area_struct,
see if you can allocate it as part of the "struct mm_struct" so that we
don't get yet another (unnecessary) allocation on fork time. I hate how
fork()  has slowed down due to other issues (mainly rmap).

Being _guaranteed_ to always have a "end marker" on the vma list would 
potentially actually simplify some of the code, but since this would be 
architecture-dependent, it wouldn't help right now. How ugly does the code 
end up being?

		Linus

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