From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, hch@infradead.org,
jgarzik@pobox.com, wli@holomorphy.com
Subject: [Patch 0/2] SGI Altix and ia64 special memory support.
Date: Wed, 12 Oct 2005 14:40:22 -0500 [thread overview]
Message-ID: <20051012194022.GE17458@lnx-holt.americas.sgi.com> (raw)
SGI hardware supports a special type of memory called fetchop or atomic
memory. This memory does atomic operations at the memory controller
instead of using the processor.
This patch set introduces a driver so user land can map the devices and
fault pages of the appropriate type. Pages are inserted on first touch.
The reason for that was hashed out earlier on the lists, but can be
distilled to node locality, node resource limitation, and application
performance.
Since a typical ia64 uncached page does not have a page struct backing it,
we first modify do_no_page to handle a new return type of NOPAGE_FAULTED.
This indicates to the nopage handler that the desired operation is
complete and should be treated as a minor fault. This is a result of a
discussion which Jes Sorenson started on the the ia64 mailing list and
Christoph Hellwig carried over to the linux-mm mailing list.
The second patch introduces the mspec driver.
I am reposting these today. The last version went out in a rush last
night and I did not take the time to notify the people that were part
of the earlier discussion.
Additionally, the version which Jes posted last April was using
remap_pfn_range(). This version uses set_pte(). I realize that is
probably the wrong thing to do. Unfortunately, we need this to be
thread-safe. With remap_pfn_range() there is a BUG_ON(!pte_none(*pte));
in remap_pte_range() which would trip if there were multiple threads
faulting at the same time. To work around that, I started looking at
breaking remap_pfn_range() into an _remap_pfn_range() which assumed
the locks were already held. At that point, it became apparent I
was stretching the use of remap_pfn_range beyond its original intent.
For this driver, we are inserting a single pte, the page tables have
already been put in place by the caller's chain, why not just insert
the pte directly. That is what I finally did.
Thanks,
Robin Holt
--
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 reply other threads:[~2005-10-12 19:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-12 19:40 Robin Holt [this message]
2005-10-12 19:41 ` [Patch 1/2] Add a NOPAGE_FAULTED flag Robin Holt
2005-10-12 19:42 ` [Patch 2/2] Special Memory (mspec) driver Robin Holt
2005-10-12 20:29 ` Jack Steiner
2005-10-14 19:14 ` Robin Holt
2005-10-14 5:12 ` Dave Hansen
2005-10-14 18:09 ` Robin Holt
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=20051012194022.GE17458@lnx-holt.americas.sgi.com \
--to=holt@sgi.com \
--cc=hch@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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