From: Michel Lespinasse <walken@google.com> To: Hugh Dickins <hughd@google.com> Cc: Rik van Riel <riel@redhat.com>, Daniel Forrest <dan.forrest@ssec.wisc.edu>, Andrea Arcangeli <aarcange@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Repeated fork() causes SLAB to grow without bound Date: Mon, 20 Aug 2012 02:39:26 -0700 [thread overview] Message-ID: <CANN689Ej7XLh8VKuaPrTttDrtDGQbXuYJgS2uKnZL2EYVTM3Dg@mail.gmail.com> (raw) In-Reply-To: <alpine.LSU.2.00.1208200032450.24855@eggly.anvils> On Mon, Aug 20, 2012 at 1:00 AM, Hugh Dickins <hughd@google.com> wrote: > On Fri, 17 Aug 2012, Rik van Riel wrote: >> Of course, that leaves the big question: do we want the >> overhead of having the atomic addition and decrement for >> every anonymous memory page, or is it easier to fix this >> issue in userspace? > > I've not given any thought to alternatives, and I've not done any > performance analysis; but my instinct says that we really do not > want another atomic increment and decrement (and another cache > line redirtied) for every single page mapped. I am concerned about this as well. > May I dare to think: what if we just backed out all the anon_vma_chain > complexity, and returned to the simple anon_vma list we had in 2.6.33? > > Just how realistic was the workload which led you to anon_vma_chains? > And isn't it correct to say that the performance evaluation was made > while believing that each anon_vma->lock was useful, before the sad > realization that anon_vma->root->lock (or ->mutex) had to be used? Thanks for suggesting this - I certainly wish we could go that way. I suspect there will be a strong case against this, but I'd certainly like to hear it (and see if it can be addressed another way). Here we just don't have processes that fork a lot of children that don't immediately exec, so anon_vmas don't bring any value for us. > I've Cc'ed Michel, because I think he has plans (or at least hopes) for > the anon_vmas, in his relentless pursuit of world domination by rbtree. Unfortunately I don't have great ideas there. It would be easy to add a flag to track if an anon_vma has ever been referenced by a struct page, and not clone the anon_vma if the flag isn't set. But, this wouldn't help at all with the DOS potential here. If there are pages referencing the anon_vma, we could reassign these to the parent anon_vma, but finding all such pages would be expensive too. Instead of adding an atomic count for page references, we could limit the anon_vma stacking depth. In fork, we would only clone anon_vmas that have a low enough generation count. I think that's not great (adds a special case for the deep-fork-without-exec behavior), but still better than the atomic page reference counter. I would still prefer if we could just remove the anon_vma_chain stuff, though. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.
WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <walken@google.com> To: Hugh Dickins <hughd@google.com> Cc: Rik van Riel <riel@redhat.com>, Daniel Forrest <dan.forrest@ssec.wisc.edu>, Andrea Arcangeli <aarcange@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Repeated fork() causes SLAB to grow without bound Date: Mon, 20 Aug 2012 02:39:26 -0700 [thread overview] Message-ID: <CANN689Ej7XLh8VKuaPrTttDrtDGQbXuYJgS2uKnZL2EYVTM3Dg@mail.gmail.com> (raw) In-Reply-To: <alpine.LSU.2.00.1208200032450.24855@eggly.anvils> On Mon, Aug 20, 2012 at 1:00 AM, Hugh Dickins <hughd@google.com> wrote: > On Fri, 17 Aug 2012, Rik van Riel wrote: >> Of course, that leaves the big question: do we want the >> overhead of having the atomic addition and decrement for >> every anonymous memory page, or is it easier to fix this >> issue in userspace? > > I've not given any thought to alternatives, and I've not done any > performance analysis; but my instinct says that we really do not > want another atomic increment and decrement (and another cache > line redirtied) for every single page mapped. I am concerned about this as well. > May I dare to think: what if we just backed out all the anon_vma_chain > complexity, and returned to the simple anon_vma list we had in 2.6.33? > > Just how realistic was the workload which led you to anon_vma_chains? > And isn't it correct to say that the performance evaluation was made > while believing that each anon_vma->lock was useful, before the sad > realization that anon_vma->root->lock (or ->mutex) had to be used? Thanks for suggesting this - I certainly wish we could go that way. I suspect there will be a strong case against this, but I'd certainly like to hear it (and see if it can be addressed another way). Here we just don't have processes that fork a lot of children that don't immediately exec, so anon_vmas don't bring any value for us. > I've Cc'ed Michel, because I think he has plans (or at least hopes) for > the anon_vmas, in his relentless pursuit of world domination by rbtree. Unfortunately I don't have great ideas there. It would be easy to add a flag to track if an anon_vma has ever been referenced by a struct page, and not clone the anon_vma if the flag isn't set. But, this wouldn't help at all with the DOS potential here. If there are pages referencing the anon_vma, we could reassign these to the parent anon_vma, but finding all such pages would be expensive too. Instead of adding an atomic count for page references, we could limit the anon_vma stacking depth. In fork, we would only clone anon_vmas that have a low enough generation count. I think that's not great (adds a special case for the deep-fork-without-exec behavior), but still better than the atomic page reference counter. I would still prefer if we could just remove the anon_vma_chain stuff, though. -- 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-08-20 9:39 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-16 2:46 Repeated fork() causes SLAB to grow without bound Daniel Forrest 2012-08-16 18:58 ` Rik van Riel 2012-08-16 18:58 ` Rik van Riel 2012-08-18 0:03 ` Daniel Forrest 2012-08-18 0:03 ` Daniel Forrest 2012-08-18 3:46 ` Rik van Riel 2012-08-18 3:46 ` Rik van Riel 2012-08-18 4:07 ` Daniel Forrest 2012-08-18 4:07 ` Daniel Forrest 2012-08-18 4:10 ` Rik van Riel 2012-08-18 4:10 ` Rik van Riel 2012-08-20 8:00 ` Hugh Dickins 2012-08-20 8:00 ` Hugh Dickins 2012-08-20 9:39 ` Michel Lespinasse [this message] 2012-08-20 9:39 ` Michel Lespinasse 2012-08-20 11:11 ` Andi Kleen 2012-08-20 11:11 ` Andi Kleen 2012-08-20 11:17 ` Rik van Riel 2012-08-20 11:17 ` Rik van Riel 2012-08-20 11:53 ` Michel Lespinasse 2012-08-20 11:53 ` Michel Lespinasse 2012-08-20 19:11 ` Michel Lespinasse 2012-08-20 19:11 ` Michel Lespinasse 2012-08-22 3:20 ` [RFC PATCH] " Michel Lespinasse 2012-08-22 3:20 ` Michel Lespinasse 2012-08-22 3:29 ` Rik van Riel 2012-08-22 3:29 ` Rik van Riel 2013-06-03 19:50 ` Daniel Forrest 2013-06-03 19:50 ` Daniel Forrest 2013-06-04 10:37 ` Rik van Riel 2013-06-04 10:37 ` Rik van Riel 2013-06-05 14:02 ` Andrea Arcangeli 2013-06-05 14:02 ` Andrea Arcangeli 2014-11-14 16:30 ` [PATCH] " Daniel Forrest 2014-11-14 16:30 ` Daniel Forrest 2014-11-18 0:02 ` Andrew Morton 2014-11-18 0:02 ` Andrew Morton 2014-11-18 1:41 ` Daniel Forrest 2014-11-18 1:41 ` Daniel Forrest 2014-11-18 2:41 ` Rik van Riel 2014-11-18 2:41 ` Rik van Riel 2014-11-18 20:19 ` Andrew Morton 2014-11-18 20:19 ` Andrew Morton 2014-11-18 22:15 ` Konstantin Khlebnikov 2014-11-18 22:15 ` Konstantin Khlebnikov 2014-11-18 23:02 ` Konstantin Khlebnikov 2014-11-18 23:50 ` Vlastimil Babka 2014-11-18 23:50 ` Vlastimil Babka 2014-11-19 14:36 ` Konstantin Khlebnikov 2014-11-19 14:36 ` Konstantin Khlebnikov 2014-11-19 16:09 ` Vlastimil Babka 2014-11-19 16:09 ` Vlastimil Babka 2014-11-19 16:58 ` Konstantin Khlebnikov 2014-11-19 16:58 ` Konstantin Khlebnikov 2014-11-19 23:14 ` Michel Lespinasse 2014-11-19 23:14 ` Michel Lespinasse 2014-11-20 14:42 ` Konstantin Khlebnikov 2014-11-20 14:42 ` Konstantin Khlebnikov 2014-11-20 14:50 ` Rik van Riel 2014-11-20 14:50 ` Rik van Riel 2014-11-20 15:03 ` Konstantin Khlebnikov 2014-11-20 15:03 ` Konstantin Khlebnikov 2014-11-24 7:09 ` Konstantin Khlebnikov 2014-11-25 10:59 ` Michal Hocko 2014-11-25 10:59 ` Michal Hocko 2014-11-25 12:13 ` Konstantin Khlebnikov 2014-11-25 15:00 ` Michal Hocko 2014-11-25 15:00 ` Michal Hocko 2014-11-26 17:35 ` Michal Hocko 2014-11-26 17:35 ` Michal Hocko 2014-12-05 15:44 ` Jerome Marchand 2014-11-20 15:27 ` Michel Lespinasse 2014-11-20 15:27 ` Michel Lespinasse 2014-11-19 2:48 ` Rik van Riel 2014-11-19 2:48 ` Rik van Riel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CANN689Ej7XLh8VKuaPrTttDrtDGQbXuYJgS2uKnZL2EYVTM3Dg@mail.gmail.com \ --to=walken@google.com \ --cc=aarcange@redhat.com \ --cc=dan.forrest@ssec.wisc.edu \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=riel@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.