From: Robin Holt <holt@sgi.com>
To: Jesse Barnes <jbarnes@sgi.com>
Cc: William Lee Irwin III <wli@holomorphy.com>,
Christoph Lameter <clameter@sgi.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: Tue, 26 Oct 2004 09:35:13 -0500 [thread overview]
Message-ID: <20041026143513.GC28391@lnx-holt.americas.sgi.com> (raw)
In-Reply-To: <200410251940.30574.jbarnes@sgi.com>
On Mon, Oct 25, 2004 at 07:40:30PM -0700, Jesse Barnes wrote:
> On Monday, October 25, 2004 7:23 pm, William Lee Irwin III wrote:
> > On Mon, Oct 25, 2004 at 06:26:42PM -0700, Christoph Lameter wrote:
> > > - Clearing hugetlb pages is time consuming using clear_highpage in
> > > alloc_huge_page. Make it possible to use hw assist via DMA or so there?
> >
> > It's possible, but it's been found not to be useful. What has been found
> > useful is assistance from much lower-level memory hardware of a kind
> > not to be had in any extant mass-manufactured machines.
>
> Do you have examples? SGI hardware has a so-called 'BTE' (for Block Transfer
> Engine) that can arbitrarily zero or copy pages w/o CPU assistance. It's
> builtin to the memory controller. Using it to zero the pages has the
> advantages of being asyncrhonous and not hosing the CPU cache.
>
Jesse,
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.
Robin
next prev parent reply other threads:[~2004-10-26 14:35 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 ` 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 [this message]
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
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=20041026143513.GC28391@lnx-holt.americas.sgi.com \
--to=holt@sgi.com \
--cc=clameter@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
all inboxes | Powered by JetHome®