On Wed, Feb 25, 2009 at 10:26 AM, Chad Mynhier <cmynh...@gmail.com> wrote: >> 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.) >
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. I was also thinking that the above problem made it all pointless, but I got at least one opinion that I can probably safely ignore the problem. (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.) Chad > Thanks, > Chad > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
