Thanks for the comments.

On Tue, Feb 24, 2009 at 5:15 PM,  <johan...@sun.com> wrote:
> 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

Fixed.

>
>  - 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.

Done.

>
> 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?

Actually, I've moved this into segvn_faultpage() where swresv is being
updated.  I'm also doing this as an atomic operation there, as I don't
have the lock there (or at least there are some cases in which I don't
have the lock there.)

>
> vm/vm_rm.c:
>
>  - lines 105-135: Dumb question -> Where is this case handled now?
>

Nope, not a dumb question, a dumb oversight on my part.  And this
might completely scupper what I want to do.  The only options I see
for doing this are either to change how we report the virtual size of
the process (i.e., ignore this case and over-report the size) or move
the accounting out into every code path that involves changing the
size of a file.  The second definitely seems a non-starter, if for no
other reason than it has the potential to introduce a performance
penalty in unexpected places (e.g., how long it takes me to append to
a file is proportional to how many processes have the file mmap'd.)
I'm guessing the first is a non-starter, too.  (I'd love to hear
someone say that's not the case.)

Thanks,
Chad
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to