Hi Chad,
You probably want a vm expert to take a look at this code, but I'm
happy to provide comments anyway.
vm/as.h:
- line 114: You probably want this member at the end of the
structure. If we end up backporting the fix, we don't want to
displace the pre-existing offsets in a struct as
- line 261: It might be worthwhile to generate a separate macro
for ((struct segvn_data *)(seg)->s_data). Since you use this
construct multiple times, it might make the AS_SEG_MAP_NORESERVE
macro easier to read. I had to paste into vim before I was able to
double-check the parenthesis.
vm/vm_as.c
- line 1039: It looks like you could be updating a_asize outsize of
a_lock. Should you be checking as_lock_held and implementing some
kind of workaround if you don't have the a_lock here?
vm/vm_rm.c:
- lines 105-135: Dumb question -> Where is this case handled now?
HTH,
-j
On Tue, Feb 24, 2009 at 03:53:02PM -0500, Chad Mynhier wrote:
> I've submitted a bug related to this problem:
> http://bugs.opensolaris.org/view_bug.do?bug_id=6801244. The gist of
> this problem is that Solaris calculates the VM size of a process when
> asked, i.e., when some utility like ps(1) or prstat(1M) reads
> /proc/<pid>/psinfo. This can be a problem on servers with many
> processes with large numbers of address space segments, as the
> relevant function, rm_assize(), does a linear traversal of the AS
> segments. I've seen ps(1) take 30 seconds or more (on an M9000) and
> prstat(1M) spending 100% of its time in sys, effectively stealing a
> CPU. Given that everyone starts running these commands when problems
> pop up, this can severely impact performance.
>
> (And note that this doesn't just impact M9000's. Jarod Jenson and I
> have started seeing this to a lesser degree on smaller boxes.)
>
> I've made the code changes to maintain the value in an extra member in
> struct as, a_asize, and update the value in as_map(), as_unmap(),
> as_dup(), as_fault(), et al. I've posted a webrev for this change
> here: http://cr.opensolaris.org/~cmynhier/6801244/.
>
>
> I'd welcome any thoughts, code reviews, and offers of sponsorship to
> get this putback.
>
> Thanks,
> Chad
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
