lkml.org 
[lkml]   [2003]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.027 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site