On Thu, Feb 26, 2009 at 2:10 PM, <johan...@sun.com> wrote: > >> (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.
I'd thought about doing something like this, i.e., updating the value infrequently one way or another. I have two objections to this: - The number reported is almost never "right". In a lot of cases, the value will be stale most of the time. - This leads to weird behavior. For example, in the environment where I most want to fix this, they run a home-grown top-like utility to gather system stats once a minute. With a 60-second timeout, this utility could take a long time to run during off-hours when there aren't other ps(1)'s taking the cache hit. (Admittedly, this might not be the strongest of arguments.) Part of the problem is the definition of the virtual size of a process WRT these segments. The current definition includes only that part of the file that exists. This matches what we do with MAP_NORESERVE segments and reflects the philosophy that we should only map those segments for which we have backing store. I'm suggesting changing that definition to be the space that a process allocates in its address space for the mapped file. I think either definition is valid, but the first definition can incur a significant performance penalty. So who would have the final say on this? Is this something that needs to go into a PSARC case, or is it less formal than that? Thanks, Chad _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
