[dtrace-discuss] /proc/<pid>/map access is sloooow when using large shared memory segments

[Mike Shapiro]

> Looks like there is a lineair relationship between segment size and
> time spend in getwatchprot.
> 
> Clues why this takes so long?

Because there is a linear relationship between segment size
and the number of iterations of pr_getprot() :)

Basically this is all about disgusting details of the current VM system.
The address space is divided into the segment ranges internally.
Within those segments there are a variety of optimizations for
dealing with having differing protections and watchpoints.
/proc has a nice model of expressing the address space in its map,
rmap, and xmap files where a "mapping" is defined as some range of
the address space that has a consistent set of attributes, in
particular a particular set of permission bits expressed in the
prmap_t structure as a single bitmap.

So when you read the map file, we have to walk the segments,
and poke at their underlying attributes to deal with the notion
that some segments have to be sliced and diced into multiple prmap_t's.
And by definition this is a linear process given the current design.

If you want to make it go faster, what you need to do is to figure
out what aspect of your segment attributes are causing pr_getprot()
to be called multiple times per segment, i.e. why we're not getting
into one the many fast-paths in there.  Depending on what you find
we may be able to add yet another one.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/