public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Uncached memory allocator for ia64.
Date: Thu, 23 Sep 2004 21:09:55 +0000	[thread overview]
Message-ID: <20040923210955.GA5477@lnx-holt.americas.sgi.com> (raw)
In-Reply-To: <20040914151629.GA21118@lnx-holt.americas.sgi.com>

On Fri, Sep 17, 2004 at 09:34:58AM -0500, Robin Holt wrote:
> 
> I have done a little testing on the uncached.  I think the problem
> may be bigger than I originally expected.

> I made a simple driver.  On load, it allocated an entire granule and,
> I think, correctly did all the flushes called for in the processor
> manual including the PAL call.  A user could then mmap the entire
> chunk as uncached and work with it.  I did not get any sort of MCAs
> from this run.

To be a little more specific, I was in section 4.4.6.1 Disabling Prefetch
and Removing Cacheability.  Jack Steiner made a comment to the effect
of there were additional steps that he knew someone had determined
were necessary.  Unfortunately, he is on vacation now.

> 
> I then started the same app which referenced the first word of each page
> uncached.  I added a timer interrupt which scanned all the page structs
> on the node from which the granule was allocated and had a reference
> to the page inside of an impossible if statement (next to impossible
> as the machine would have to be up for a large number of years).
> This, I believe, resulted in the speculation of the cache line dirty.
> By running this test for about 8 minutes, I was able to cause an MCA
> due to having both a cached and uncached reference to the same cache
> line on the FSB.

> Note, I was running all the pages structs for the node and not just
> the ones for this granule.

> Based on this test, I was wondering if it is safe to reuse a granule
> and leave the page structs in place.  Is this test representative
> of events which could happen?  Can we destroy the page structs on a
> running system?

> Thank you in advance for any direction anybody can give me.

I am not sure what will be acceptable at this point.  Should I write
an uncached allocator which grabs the granules at boot time before they
are ever initialized for cacheable use?  If so, would it be acceptable
to just shrink each efi memory map entry by a command line specified
size during the efi_memmap_walk callout?  At this point I am so vague
on what I should be doing that I am afraid to do much of anything.

Thanks again,
Robin Holt

  parent reply	other threads:[~2004-09-23 21:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-14 15:16 Uncached memory allocator for ia64 Robin Holt
2004-09-15  8:23 ` David Mosberger
2004-09-15 11:04 ` Robin Holt
2004-09-15 11:14 ` David Mosberger
2004-09-17 14:34 ` Robin Holt
2004-09-23 21:09 ` Robin Holt [this message]
2004-09-23 22:12 ` Luck, Tony
2004-09-23 23:01 ` Robin Holt
2004-09-25 12:40 ` Robin Holt
2004-09-29 14:24 ` David Mosberger
2004-09-29 15:43 ` Robin Holt
2004-09-29 16:02 ` David Mosberger

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=20040923210955.GA5477@lnx-holt.americas.sgi.com \
    --to=holt@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /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