From: William Lee Irwin III <wli@holomorphy.com> To: "Chen, Kenneth W" <kenneth.w.chen@intel.com> Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, "Seth, Rohit" <rohit.seth@intel.com> Subject: Re: Hugetlb demanding paging for -mm tree Date: Mon, 9 Aug 2004 12:12:40 -0700 [thread overview] Message-ID: <20040809191240.GS11200@holomorphy.com> (raw) In-Reply-To: <200408091854.i79IsCY12450@unix-os.sc.intel.com> William Lee Irwin III wrote on Saturday, August 07, 2004 1:36 AM >> This is needed because we're only freeing pagetables at pgd granularity >> at munmap() -time. It makes more sense to refine it to pmd granularity >> instead of this cleanup pass, as it's a memory leak beyond just hugetlb >> data structure corruption. On Mon, Aug 09, 2004 at 11:54:13AM -0700, Chen, Kenneth W wrote: > That would be nice and ease the pain on x86. OTOH, leaving pte persistent > right now may help in mmap/munmap intensive workload since unmap_region() > only destroys all pte allocation at pgd granularity. We're better off caching pagetables for that. I don't appear to be able to get the code to cache 3rd-level pagetables on ia32 past permavetoes. William Lee Irwin III wrote on Saturday, August 07, 2004 1:36 AM >> I wonder why this bugfix was rolled into the demand paging patch instead >> of shipped separately. And for that matter, this fix applies to mainline. On Mon, Aug 09, 2004 at 11:54:13AM -0700, Chen, Kenneth W wrote: > The bug fix went into hugetlb_prefault() function in the mainline for the > prefaulting case. It went to that function instead of huge_pte_alloc > and huge_pte_offset is to avoid scrubbing at pte lookup time. One > thing we can do for demand paging case is to scrub it at initial mmap > hugetlb vma, so the penalty is paid upfront instead of at every pte > allocation/lookup time. Good thing I brought a barfbag back from the OLS return flight... the leak really is a major issue, esp. on 64-bit where vast amounts of virtualspace are mapped and hence vast amounts of pagetables may leak. I'll put the pagetable cleanup on my TODO along with ia64 pagetable caching (which should be as easy as it was for ppc64). -- wli
WARNING: multiple messages have this Message-ID (diff)
From: William Lee Irwin III <wli@holomorphy.com> To: "Chen, Kenneth W" <kenneth.w.chen@intel.com> Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, "Seth, Rohit" <rohit.seth@intel.com> Subject: Re: Hugetlb demanding paging for -mm tree Date: Mon, 09 Aug 2004 19:12:40 +0000 [thread overview] Message-ID: <20040809191240.GS11200@holomorphy.com> (raw) In-Reply-To: <200408091854.i79IsCY12450@unix-os.sc.intel.com> William Lee Irwin III wrote on Saturday, August 07, 2004 1:36 AM >> This is needed because we're only freeing pagetables at pgd granularity >> at munmap() -time. It makes more sense to refine it to pmd granularity >> instead of this cleanup pass, as it's a memory leak beyond just hugetlb >> data structure corruption. On Mon, Aug 09, 2004 at 11:54:13AM -0700, Chen, Kenneth W wrote: > That would be nice and ease the pain on x86. OTOH, leaving pte persistent > right now may help in mmap/munmap intensive workload since unmap_region() > only destroys all pte allocation at pgd granularity. We're better off caching pagetables for that. I don't appear to be able to get the code to cache 3rd-level pagetables on ia32 past permavetoes. William Lee Irwin III wrote on Saturday, August 07, 2004 1:36 AM >> I wonder why this bugfix was rolled into the demand paging patch instead >> of shipped separately. And for that matter, this fix applies to mainline. On Mon, Aug 09, 2004 at 11:54:13AM -0700, Chen, Kenneth W wrote: > The bug fix went into hugetlb_prefault() function in the mainline for the > prefaulting case. It went to that function instead of huge_pte_alloc > and huge_pte_offset is to avoid scrubbing at pte lookup time. One > thing we can do for demand paging case is to scrub it at initial mmap > hugetlb vma, so the penalty is paid upfront instead of at every pte > allocation/lookup time. Good thing I brought a barfbag back from the OLS return flight... the leak really is a major issue, esp. on 64-bit where vast amounts of virtualspace are mapped and hence vast amounts of pagetables may leak. I'll put the pagetable cleanup on my TODO along with ia64 pagetable caching (which should be as easy as it was for ppc64). -- wli
next prev parent reply other threads:[~2004-08-09 19:14 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-08-05 13:29 Hugetlb demanding paging for -mm tree Chen, Kenneth W 2004-08-05 13:29 ` Chen, Kenneth W 2004-08-05 13:36 ` William Lee Irwin III 2004-08-05 13:36 ` William Lee Irwin III 2004-08-05 13:39 ` Chen, Kenneth W 2004-08-05 13:39 ` Chen, Kenneth W 2004-08-05 16:35 ` Hirokazu Takahashi 2004-08-05 16:35 ` Hirokazu Takahashi 2004-08-06 20:55 ` Chen, Kenneth W 2004-08-06 20:55 ` Chen, Kenneth W 2004-08-06 21:07 ` William Lee Irwin III 2004-08-06 21:07 ` William Lee Irwin III 2004-08-07 8:13 ` William Lee Irwin III 2004-08-07 8:13 ` William Lee Irwin III 2004-08-09 18:19 ` Chen, Kenneth W 2004-08-09 18:19 ` Chen, Kenneth W 2004-08-09 19:12 ` William Lee Irwin III 2004-08-09 19:12 ` William Lee Irwin III 2004-08-07 8:36 ` William Lee Irwin III 2004-08-07 8:36 ` William Lee Irwin III 2004-08-09 18:54 ` Chen, Kenneth W 2004-08-09 18:54 ` Chen, Kenneth W 2004-08-09 19:12 ` William Lee Irwin III [this message] 2004-08-09 19:12 ` William Lee Irwin III 2004-08-05 13:42 ` Chen, Kenneth W 2004-08-05 13:42 ` Chen, Kenneth W 2004-08-05 14:04 ` Andi Kleen 2004-08-05 14:04 ` Andi Kleen 2004-08-06 21:06 ` Chen, Kenneth W 2004-08-06 21:06 ` Chen, Kenneth W 2004-08-05 13:43 ` Andi Kleen 2004-08-05 13:43 ` Andi Kleen 2004-08-09 18:43 Seth, Rohit 2004-08-09 18:43 ` Seth, Rohit 2004-08-09 18:59 ` William Lee Irwin III 2004-08-09 18:59 ` William Lee Irwin III 2004-08-10 8:52 Seth, Rohit 2004-08-10 8:52 ` Seth, Rohit 2004-08-10 8:55 ` William Lee Irwin III 2004-08-10 8:55 ` William Lee Irwin III 2004-08-11 0:28 Seth, Rohit 2004-08-11 0:28 ` Seth, Rohit 2004-08-11 0:45 ` William Lee Irwin III 2004-08-11 0:45 ` William Lee Irwin III 2004-08-11 6:36 Seth, Rohit 2004-08-11 6:36 ` Seth, Rohit 2004-08-11 6:38 ` William Lee Irwin III 2004-08-11 6:38 ` William Lee Irwin III
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=20040809191240.GS11200@holomorphy.com \ --to=wli@holomorphy.com \ --cc=kenneth.w.chen@intel.com \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rohit.seth@intel.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.