On 10/21/2015 04:39 PM, Vlastimil Babka wrote: > On 10/05/2015 05:01 AM, Hugh Dickins wrote: >> On Fri, 2 Oct 2015, Vlastimil Babka wrote: >> As you acknowledge in the commit message, if a file of 100 pages >> were copied to tmpfs, and 100 tasks map its full extent, but they >> all mess around with the first 50 pages and take no interest in >> the last 50, then it's quite likely that that last 50 will get >> swapped out; then with your patch, 100 tasks are each shown as >> using 50 pages of swap, when none of them are actually using any. > > Yeah, but isn't it the same with private memory which was swapped out at > some point and we don't know if it will be touched or not? The > difference is in private case we know the process touched it at least > once, but that can also mean nothing for the future (or maybe it just > mmapped with MAP_POPULATE and didn't care about half of it). > > That's basically what I was trying to say in the changelog. I interpret > the Swap: value as the amount of swap-in potential, if the process was > going to access it, which is what the particular customer also expects > (see below). In that case showing zero is IMHO wrong and inconsistent > with the anonymous private mappings. I didn't understand the changelog that way an IMHO it's a pretty specific interpretation. I've always understood memory accounting as being primarily the answer to the question: how much resources a process uses? I guess its meaning as been overloaded with corollaries that are only true in the most simple non-shared cases, such as yours or "how much memory would be freed if this process goes away?", but I don't think it should ever be used as a definition. I suppose the reason I didn't understand the changelog the way you intended is because I think that sometimes it's correct to blame a process for pages it never accessed (and I also believe that over-accounting is better that under accounting, but I must admit that it is a quite arbitrary point of view). For instance, what if a process has a shared anonymous mapping that includes pages that it never accessed, but have been populated by an other process that has already exited or munmaped the range? That process is not to blame for the appearance of these pages, but it's the only reason why they stay. I'll offer a lollipop to anyone who comes up with a simple consistent model on how to account shmem pages for all the possible cases, a "Grand Unified Theory of Memory Accounting" so to speak. > Other non-perfect solutions that come to mind: > > 1) For private mappings, count only the swapents. "Swap:" is no longer > showing full swap-in potential though. > 2) For private mappings, do not count swapents. Ditto. > 3) Provide two separate counters. The user won't know how much they > overlap, though. > > From these I would be inclined towards 3) as being more universal, > although then it's no longer a simple "we're fixing a Swap: 0 value > which is wrong", but closer to original Jerome's versions, which IIRC > introduced several shmem-specific counters. You remember correctly. Given all the controversy around shmem accounting, maybe it would indeed be better to leave existing counters, that are relatively well defined and understood, untouched and add specific counters to mess around instead. Thanks, Jerome
Attachment:
signature.asc
Description: OpenPGP digital signature
