On Mon, Aug 20, 2012 at 4:17 AM, Rik van Riel <riel@xxxxxxxxxx> wrote: > Without the anon_vma_chains, we end up scanning every single > one of the child processes (and the parent) for every COWed > page, which can be a real issue when the VM runs into 1000 > such pages, for 1000 child processes. > > Unfortunately, we have seen this happen... Well, it only happens if the vma is created in the parent, and the first anon write also happens in the parent. I suppose that's a legitimate thing to do in a forking server though - say, for an expensive initialization stage, or precomputing some table, or whatever. When fork happens after the first anon page has been created, the child VMA currently ends up being added to the parent's anon_vma - even if the child might never create new anon pages into that VMA. I wonder if it might help to add the child VMA onto the parent's anon_vma only at the first child COW event. That way it would at least be possible (with userspace changes) for any forking servers to separate the areas they want to write into from the parent (such as things that need expensive initialization), from the ones that they want to write into from the child, and have none of the anon_vma lists grow too large. This might still be impractical if one has too many such workloads to care about. I'm just not sure how prevalent the problem workloads are. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>