From: Ray Bryant <raybry@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Robin Holt <holt@sgi.com>, Jesse Barnes <jbarnes@sgi.com>,
William Lee Irwin III <wli@holomorphy.com>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: Hugepages demand paging V2 [0/8]: Discussion and overview
Date: Wed, 27 Oct 2004 18:08:47 -0500 [thread overview]
Message-ID: <41802A7F.7020001@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0410271103500.18165@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Tue, 26 Oct 2004, Robin Holt wrote:
>
>
>>Sorry for being a stickler here, but the BTE is really part of the
>>I/O Interface portion of the shub. That portion has a seperate clock
>>frequency from the memory controller (unfortunately slower). The BTE
>>can zero at a slightly slower speed than the processor. It does, as
>>you pointed out, not trash the CPU cache.
>>
>>One other feature of the BTE is it can operate asynchronously from
>>the cpu. This could be used to, during a clock interrupt, schedule
>>additional huge page zero filling on multiple nodes at the same time.
>>This could result in a huge speed boost on machines that have multiple
>>memory only nodes. That has not been tested thoroughly. We have done
>>considerable testing of the page zero functionality as well as the
>>error handling.
>
>
> If the huge patch would support some way of redirecting the clearing of a
> huge page then we could:
>
> 1. set the huge pte to not present so that we get a fault on access
> 2. run the bte clearer.
> 3. On receiving a huge fault we could check for the bte being finished.
>
> This would parallelize the clearing of huge pages. But is that really more
> efficient? There may be complexity involved in allowing the clearing of
> multiple pages and tracking of the clear in progress is additional
> overhead.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Another point is that if you zero pages off line from the application,
then depending on how many pre-zeroed pages an application finds, its
execution time may not be repeatable. I. e. if the system has been idle
a long time, then the BTEs will have zeroed all of the allocated hugetlbpags
and startup will be fast. But then the next time the application runs, those
pages it used and released will have to be zeroed before it can run. I think
I would vote for repeatability here rather than using the BTE offline to
zero pages.
--
Best Regards,
Ray
-----------------------------------------------
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
raybry@sgi.com raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
so I installed Linux.
-----------------------------------------------
next prev parent reply other threads:[~2004-10-27 23:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <B05667366EE6204181EABE9C1B1C0EB504BFA47C@scsmsx401.amr.corp.intel.com>
2004-10-26 1:26 ` Hugepages demand paging V2 [0/8]: Discussion and overview Christoph Lameter
2004-10-26 1:27 ` Hugepages demand paging V2 [1/8]: hugetlb fault handler Christoph Lameter
2005-01-18 12:21 ` Hirokazu Takahashi
2005-01-18 16:33 ` Christoph Lameter
2004-10-26 1:28 ` Hugepages demand paging V2 [2/8]: allocation control Christoph Lameter
2004-10-26 1:28 ` Hugepages demand paging V2 [3/8]: simple numa compatible allocator Christoph Lameter
2005-02-02 12:21 ` Hirokazu Takahashi
2004-10-26 1:29 ` Hugepages demand paging V2 [4/8]: ia64 arch modifications Christoph Lameter
2004-10-26 1:29 ` Hugepages demand paging V2 [5/8]: i386 " Christoph Lameter
2004-10-26 1:30 ` Hugepages demand paging V2 [6/8]: sparc64 " Christoph Lameter
2004-10-26 1:31 ` Hugepages demand paging V2 [7/8]: sh64 " Christoph Lameter
2004-10-26 1:31 ` Hugepages demand paging V2 [8/8]: sh arch specific modifications Christoph Lameter
2004-10-26 2:23 ` Hugepages demand paging V2 [0/8]: Discussion and overview William Lee Irwin III
2004-10-26 2:40 ` Jesse Barnes
2004-10-26 2:43 ` William Lee Irwin III
2004-10-26 14:35 ` Robin Holt
2004-10-26 16:44 ` Jesse Barnes
2004-10-26 17:40 ` William Lee Irwin III
2004-10-26 17:45 ` Christoph Lameter
2004-10-26 17:47 ` William Lee Irwin III
2004-10-27 18:06 ` Christoph Lameter
2004-10-27 23:01 ` Ray Bryant
2004-10-28 11:51 ` Robin Holt
2004-10-28 16:34 ` Ray Bryant
2004-10-27 23:08 ` Ray Bryant [this message]
2004-10-27 5:23 ` David Gibson
2004-10-27 16:25 ` Christoph Lameter
2004-10-27 6:48 ` William Lee Irwin III
2004-10-27 14:21 ` Ray Bryant
2004-10-27 16:30 ` Christoph Lameter
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=41802A7F.7020001@sgi.com \
--to=raybry@sgi.com \
--cc=clameter@sgi.com \
--cc=holt@sgi.com \
--cc=jbarnes@sgi.com \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).