Messages in this thread | | | Date | Sun, 12 Oct 2003 18:49:56 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] report user-readable fixmap area in /proc/PID/maps |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |