Hi Chad, > BTW, I've posted an updated webrev here: > http://cr.opensolaris.org/~cmynhier/6801244.1/. I wanted to do a > nightly build and some testing before posting it.
This looks better. Thanks for making the changes we discussed before. > > 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. > (To expand on the problem a bit, the problem comes when a process maps > a file into a segment that's larger than the file, e.g., mapping a 1K > file into a 10K segment. Currently rm_assize() will only count the > space used through the end of the file (on a page boundary), so my > version will report a larger number than rm_assize() currently returns > in these cases.) I honestly don't know whether it's okay to over-report the size of these segments. My guess is that nobody will notice; however, I can think of a couple of other possibilities for handling the discrepancy. One approach might be to check a_ssize, but every 30-60 seconds allow a call to the slow path (rm_assize()). Another possibility might be to check the size of the segment against the file in an operation that's slow and infrequently called. You could overreport the size of the segment until segvn_sync() is called. In that code path, we've got to flush dirty pages anyway, so it probably wouldn't be too much additional overhead to also check segsize against filesize. In this case, you're just checking the segments that are sync'd so it's probably less work than allowing a periodic call to rm_assize. HTH, -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
