cacheble to uncachble change

cacheble to uncachble change

[Mario Smarduch]

Is there support in IA64 kernel to change a memory mapping from
cacheble to uncacheble  attribute. By support I mean one function
which can accept an addr start/range,  make sure in-transit
cache data/prefetch  hits are synced and upon return gurantee
no CPU has any stale data in its caches and after installing the new
attribute memory is guranteed synchronized. Or is a combonition
of functions/macros required?

- Mario

Re: cacheble to uncachble change

[David Mosberger]

>>>>> On Mon, 26 Apr 2004 14:00:40 -0500, Mario Smarduch <cms063@email.mot.com> said:

  Mario> Is there support in IA64 kernel to change a memory mapping
  Mario> from cacheble to uncacheble attribute. By support I mean one
  Mario> function which can accept an addr start/range, make sure
  Mario> in-transit cache data/prefetch hits are synced and upon
  Mario> return gurantee no CPU has any stale data in its caches and
  Mario> after installing the new attribute memory is guranteed
  Mario> synchronized. Or is a combonition of functions/macros
  Mario> required?

Volume 2 (System Architecture) of the ASDM outlines the steps needed
to do such a transition.  All the necessary primitives should be there
in ia64 linux, but there is no single convenient-to-use function to do
this.

In any case, just be careful about not introducing memory attribute
aliases.  You need to be especially careful since the kernel accesses
memory with granule-sized mappings (normally 64MB page size, but on
some machines its 16MB).

	--david

RE: cacheble to uncachble change

[Jim Hull]

In addition to what David wrote, which I completely agree with, you also need to
be aware that it is platform dependent whether any particular address range
supports cacheable, uncacheable, or both attributes.  System firmware
communicates to the OS which attributes are allowed for which address ranges.
I'm not familiar with how ia64-linux exposes this info within the kernel (maybe
David could fill you in).

 -- Jim
    HP Itanium Processor Architect

> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org 
> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of David Mosberger
> Sent: Monday, April 26, 2004 12:25 PM
> To: Mario Smarduch
> Cc: IA-64 Mailing List (New)
> Subject: Re: cacheble to uncachble change
> 
> 
> >>>>> On Mon, 26 Apr 2004 14:00:40 -0500, Mario Smarduch 
> <cms063@email.mot.com> said:
> 
>   Mario> Is there support in IA64 kernel to change a memory mapping
>   Mario> from cacheble to uncacheble attribute. By support I mean one
>   Mario> function which can accept an addr start/range, make sure
>   Mario> in-transit cache data/prefetch hits are synced and upon
>   Mario> return gurantee no CPU has any stale data in its caches and
>   Mario> after installing the new attribute memory is guranteed
>   Mario> synchronized. Or is a combonition of functions/macros
>   Mario> required?
> 
> Volume 2 (System Architecture) of the ASDM outlines the steps needed
> to do such a transition.  All the necessary primitives should be there
> in ia64 linux, but there is no single convenient-to-use function to do
> this.
> 
> In any case, just be careful about not introducing memory attribute
> aliases.  You need to be especially careful since the kernel accesses
> memory with granule-sized mappings (normally 64MB page size, but on
> some machines its 16MB).
> 
> 	--david
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: cacheble to uncachble change

[Robin Holt]

On Mon, Apr 26, 2004 at 12:25:03PM -0700, David Mosberger wrote:
> >>>>> On Mon, 26 Apr 2004 14:00:40 -0500, Mario Smarduch <cms063@email.mot.com> said:
> 
>   Mario> Is there support in IA64 kernel to change a memory mapping
>   Mario> from cacheble to uncacheble attribute. By support I mean one
>   Mario> function which can accept an addr start/range, make sure
>   Mario> in-transit cache data/prefetch hits are synced and upon
>   Mario> return gurantee no CPU has any stale data in its caches and
>   Mario> after installing the new attribute memory is guranteed
>   Mario> synchronized. Or is a combonition of functions/macros
>   Mario> required?
> 
> Volume 2 (System Architecture) of the ASDM outlines the steps needed
> to do such a transition.  All the necessary primitives should be there
> in ia64 linux, but there is no single convenient-to-use function to do
> this.
> 
> In any case, just be careful about not introducing memory attribute
> aliases.  You need to be especially careful since the kernel accesses
> memory with granule-sized mappings (normally 64MB page size, but on
> some machines its 16MB).

Be very careful when using uncached memory.  On the SGI systems, we
always allocate memory for uncached out of a seperate granule.  We were
experiencing memory corruption due to kernel speculative load which
fetched the cache line dirty.  This would result in cache lines that were
occasionally out of date.  The problem was resolved on our kernels by
drivers/char/fetchop.c which provides a seperate device for mapping
when you want uncached or write coalesced memory.

Good Luck,
Robin Holt

RE: cacheble to uncachble change

[David Mosberger]

>>>>> On Mon, 26 Apr 2004 14:24:58 -0700, "Jim Hull" <jim.hull@hp.com> said:

  Jim> In addition to what David wrote, which I completely agree with,
  Jim> you also need to be aware that it is platform dependent whether
  Jim> any particular address range supports cacheable, uncacheable,
  Jim> or both attributes.  System firmware communicates to the OS
  Jim> which attributes are allowed for which address ranges.  I'm not
  Jim> familiar with how ia64-linux exposes this info within the
  Jim> kernel (maybe David could fill you in).

The EFI memory attributes for a particular physical address can be
looked up in ia64 linux via:

 unsigned long efi_mem_attributes (unsigned long phys_addr);

	--david

Re: cacheble to uncachble change

[David Mosberger]

>>>>> On Mon, 26 Apr 2004 16:35:55 -0500, Robin Holt <holt@sgi.com> said:

  >> In any case, just be careful about not introducing memory attribute
  >> aliases.  You need to be especially careful since the kernel accesses
  >> memory with granule-sized mappings (normally 64MB page size, but on
  >> some machines its 16MB).

  Robin> Be very careful when using uncached memory.  On the SGI
  Robin> systems, we always allocate memory for uncached out of a
  Robin> seperate granule.  We were experiencing memory corruption due
  Robin> to kernel speculative load which fetched the cache line
  Robin> dirty.  This would result in cache lines that were
  Robin> occasionally out of date.  The problem was resolved on our
  Robin> kernels by drivers/char/fetchop.c which provides a seperate
  Robin> device for mapping when you want uncached or write coalesced
  Robin> memory.

Are you just re-stating my caveat about memory-attribute-aliasing or
are you saying something else?  If the latter, I'm not following.  If
the former, I certainly agree: memory attribute-aliasing leads to
really nasty-to-track-down bugs.  Hence, you want to make sure
_upfront_ that it doesn't occur.

	--david

Re: cacheble to uncachble change

[Robin Holt]

On Mon, Apr 26, 2004 at 05:03:23PM -0700, David Mosberger wrote:
> >>>>> On Mon, 26 Apr 2004 16:35:55 -0500, Robin Holt <holt@sgi.com> said:
> 
> 
> Are you just re-stating my caveat about memory-attribute-aliasing or
> are you saying something else?  If the latter, I'm not following.  If
> the former, I certainly agree: memory attribute-aliasing leads to
> really nasty-to-track-down bugs.  Hence, you want to make sure
> _upfront_ that it doesn't occur.

Restating.  Don't you love the person who plays the master of the obvious
role.  I started writing the email and was at the same time looking for
examples of kernel code from 2.4 which we had found that was speculating
addresses and was going to hopefully point out how difficult it was
for us to track down.  Unfortunately, I never found the bugs in our
internal bug tracking system.  I am not sure we ever actually found
the source of the corruption, only that it was occuring.

Sorry,
Robin Holt

Re: cacheble to uncachble change

[Jack Steiner]

On Tue, Apr 27, 2004 at 05:52:28AM -0500, Robin Holt wrote:
> On Mon, Apr 26, 2004 at 05:03:23PM -0700, David Mosberger wrote:
> > >>>>> On Mon, 26 Apr 2004 16:35:55 -0500, Robin Holt <holt@sgi.com> said:
> > 
> > 
> > Are you just re-stating my caveat about memory-attribute-aliasing or
> > are you saying something else?  If the latter, I'm not following.  If
> > the former, I certainly agree: memory attribute-aliasing leads to
> > really nasty-to-track-down bugs.  Hence, you want to make sure
> > _upfront_ that it doesn't occur.
> 
> Restating.  Don't you love the person who plays the master of the obvious
> role.  I started writing the email and was at the same time looking for
> examples of kernel code from 2.4 which we had found that was speculating

IIRC, one place that got us in trouble in 2.4 was in free_one_pgd(). The code
prefetches a dirty cacheline that is one cache line BEYOND the
end of the PT page. The line is marked dirty (prefetchw()) in the cache even 
though the function does not actually modify it. The line will subsequently be
written back to memory. If the following page is in the same granule &
is being used uncached (memory-attribute-aliasing), bad things will
happen......





> addresses and was going to hopefully point out how difficult it was
> for us to track down.  Unfortunately, I never found the bugs in our
> internal bug tracking system.  I am not sure we ever actually found
> the source of the corruption, only that it was occuring.
> 
> Sorry,
> Robin Holt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.

Re: cacheble to uncachble change

[David Mosberger]

>>>>> On Tue, 27 Apr 2004 09:24:41 -0500, Jack Steiner <steiner@sgi.com> said:

  Jack> On Tue, Apr 27, 2004 at 05:52:28AM -0500, Robin Holt wrote:
  >> On Mon, Apr 26, 2004 at 05:03:23PM -0700, David Mosberger wrote:
  >> > >>>>> On Mon, 26 Apr 2004 16:35:55 -0500, Robin Holt <holt@sgi.com> said:
  >> > Are you just re-stating my caveat about memory-attribute-aliasing or
  >> > are you saying something else?  If the latter, I'm not following.  If
  >> > the former, I certainly agree: memory attribute-aliasing leads to
  >> > really nasty-to-track-down bugs.  Hence, you want to make sure
  >> > _upfront_ that it doesn't occur.

  >> Restating.  Don't you love the person who plays the master of the obvious
  >> role.  I started writing the email and was at the same time looking for
  >> examples of kernel code from 2.4 which we had found that was speculating

  Jack> IIRC, one place that got us in trouble in 2.4 was in
  Jack> free_one_pgd(). The code prefetches a dirty cacheline that is
  Jack> one cache line BEYOND the end of the PT page. The line is
  Jack> marked dirty (prefetchw()) in the cache even though the
  Jack> function does not actually modify it. The line will
  Jack> subsequently be written back to memory. If the following page
  Jack> is in the same granule & is being used uncached
  Jack> (memory-attribute-aliasing), bad things will happen......

Yes, of course.  Violating a correctness requirement (no
memory-attribute aliasing) can cause bad things to happen.  Duh.

I don't mean this as a criticism.  I only want to be clear that the
bug here was caused by ignoring a correctness requirement ("no
attribute aliasing").  The kernel is perfectly entitled to prefetch
any address of its choosing.  In fact, even without explicit data
prefetches, you'll get implicit code prefetching (not to mention
speculative loads when using a modern compiler).

The moral of the story: we're not kidding when we say memory-attribute
aliasing needs to be taken seriously.  (And it's not an ia64-only
concern, as the nasty AGP-related attribute-aliasing bug revealed on
Linux for certain x86 CPUs.)

	--david

Re: cacheble to uncachble change

[Jack Steiner]

On Tue, Apr 27, 2004 at 12:50:16PM -0700, David Mosberger wrote:
> >>>>> On Tue, 27 Apr 2004 09:24:41 -0500, Jack Steiner <steiner@sgi.com> said:
> 
>   Jack> On Tue, Apr 27, 2004 at 05:52:28AM -0500, Robin Holt wrote:
>   >> On Mon, Apr 26, 2004 at 05:03:23PM -0700, David Mosberger wrote:
>   >> > >>>>> On Mon, 26 Apr 2004 16:35:55 -0500, Robin Holt <holt@sgi.com> said:
>   >> > Are you just re-stating my caveat about memory-attribute-aliasing or
>   >> > are you saying something else?  If the latter, I'm not following.  If
>   >> > the former, I certainly agree: memory attribute-aliasing leads to
>   >> > really nasty-to-track-down bugs.  Hence, you want to make sure
>   >> > _upfront_ that it doesn't occur.
> 
>   >> Restating.  Don't you love the person who plays the master of the obvious
>   >> role.  I started writing the email and was at the same time looking for
>   >> examples of kernel code from 2.4 which we had found that was speculating
> 
>   Jack> IIRC, one place that got us in trouble in 2.4 was in
>   Jack> free_one_pgd(). The code prefetches a dirty cacheline that is
>   Jack> one cache line BEYOND the end of the PT page. The line is
>   Jack> marked dirty (prefetchw()) in the cache even though the
>   Jack> function does not actually modify it. The line will
>   Jack> subsequently be written back to memory. If the following page
>   Jack> is in the same granule & is being used uncached
>   Jack> (memory-attribute-aliasing), bad things will happen......
> 
> Yes, of course.  Violating a correctness requirement (no
> memory-attribute aliasing) can cause bad things to happen.  Duh.

Maybe I was not clear. I *know* that memory attribute aliasing is a bad
thing to do. I was commenting on Robin's mail and providing a real-life
example on where/how it causes problems. Prefetching is a perfectly
valid thing for the cpu to do. Any time there is a valid TLB entry, prefetching
can & will happen. DONT allow a TLB entry to cover both cached &
uncached pages.


> 
> I don't mean this as a criticism.  I only want to be clear that the
> bug here was caused by ignoring a correctness requirement ("no
> attribute aliasing").  The kernel is perfectly entitled to prefetch
> any address of its choosing.  In fact, even without explicit data
> prefetches, you'll get implicit code prefetching (not to mention
> speculative loads when using a modern compiler).
> 
> The moral of the story: we're not kidding when we say memory-attribute
> aliasing needs to be taken seriously.  (And it's not an ia64-only
> concern, as the nasty AGP-related attribute-aliasing bug revealed on
> Linux for certain x86 CPUs.)
> 
> 	--david

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.

Re: cacheble to uncachble change

[David Mosberger]

>>>>> On Tue, 27 Apr 2004 16:31:57 -0500, Jack Steiner <steiner@sgi.com> said:

  Jack> Maybe I was not clear. I *know* that memory attribute aliasing
  Jack> is a bad thing to do. I was commenting on Robin's mail and
  Jack> providing a real-life example on where/how it causes
  Jack> problems. Prefetching is a perfectly valid thing for the cpu
  Jack> to do. Any time there is a valid TLB entry, prefetching can &
  Jack> will happen. DONT allow a TLB entry to cover both cached &
  Jack> uncached pages.

Sounds like we're in violent agreement! ;-)

	--david

Re: cacheble to uncachble change

[Mario Smarduch]

David Mosberger wrote:

> >>>>> On Tue, 27 Apr 2004 16:31:57 -0500, Jack Steiner <steiner@sgi.com> said:
>
>   Jack> Maybe I was not clear. I *know* that memory attribute aliasing
>   Jack> is a bad thing to do. I was commenting on Robin's mail and
>   Jack> providing a real-life example on where/how it causes
>   Jack> problems. Prefetching is a perfectly valid thing for the cpu
>   Jack> to do. Any time there is a valid TLB entry, prefetching can &
>   Jack> will happen. DONT allow a TLB entry to cover both cached &
>   Jack> uncached pages.
>
> Sounds like we're in violent agreement! ;-)
>
>         --david

I guess the question wasn't so much about attribute aliasing but
killing all intransit memory accesses and prefetch before its
safe to change the TLB attribute to uncacheble, with assurance that
all new mem refs/prefetch will come from memory. I appreciate
all your inputs.

- Mario.

Re: cacheble to uncachble change

[David Mosberger]

>>>>> On Tue, 27 Apr 2004 17:35:10 -0500, Mario Smarduch <cms063@email.mot.com> said:

  Mario> I guess the question wasn't so much about attribute aliasing
  Mario> but killing all intransit memory accesses and prefetch before
  Mario> its safe to change the TLB attribute to uncacheble, with
  Mario> assurance that all new mem refs/prefetch will come from
  Mario> memory. I appreciate all your inputs.

Yes, but that's the _easy_ part, so to speak.

To be honest, I would appreciate if you could outline your strategy to
avoid memory-attribute aliasing.  If only because it would give me a
warm-and-fuzzy feeling... ;-)

If this isn't something you're comfortable discussing on a public
list, a private mail would still be appreciated.

Thanks,

	--david

RE: cacheble to uncachble change

[Luck, Tony]

>  Mario> I guess the question wasn't so much about attribute aliasing
>  Mario> but killing all intransit memory accesses and prefetch before
>  Mario> its safe to change the TLB attribute to uncacheble, with
>  Mario> assurance that all new mem refs/prefetch will come from
>  Mario> memory. I appreciate all your inputs.
>
>  David>Yes, but that's the _easy_ part, so to speak.

Buried in one of the e-mails on this thread was the fact that you must
allocate a whole granule (16MB or 64MB ... check your .config) to make
sure that you don't have a kernel cacheable mapping setup by the
Alt-DTLB
miss handler.

-Tony

Re: cacheble to uncachble change

[Robin Holt]

On Tue, Apr 27, 2004 at 03:45:48PM -0700, David Mosberger wrote:
> 
> Yes, but that's the _easy_ part, so to speak.
> 
> To be honest, I would appreciate if you could outline your strategy to
> avoid memory-attribute aliasing.  If only because it would give me a
> warm-and-fuzzy feeling... ;-)
> 
> If this isn't something you're comfortable discussing on a public
> list, a private mail would still be appreciated.

I think this is important enough to SGI that we would like to be
included in this discussion.  One of our employees started working
on adapting what is currently the needing to be renamed fetchop
driver to take a whole granule when there are no remaining pages
in the uncached drivers space, doing the flushes, sync.i, srlz.i
sequences to ensure all cache lines are flushed and then shoot down
the existing TLB entries before adding the pages of the granule to
the uncached drivers space.  This sounds similar to what is being
proposed here, I believe.

Thanks,
Robin

Re: cacheble to uncachble change

[Mario Smarduch]

Robin Holt wrote:

> On Tue, Apr 27, 2004 at 03:45:48PM -0700, David Mosberger wrote:
> >
> > Yes, but that's the _easy_ part, so to speak.
> >
> > To be honest, I would appreciate if you could outline your strategy to
> > avoid memory-attribute aliasing.  If only because it would give me a
> > warm-and-fuzzy feeling... ;-)
> >
> > If this isn't something you're comfortable discussing on a public
> > list, a private mail would still be appreciated.
>
> I think this is important enough to SGI that we would like to be
> included in this discussion.  One of our employees started working
> on adapting what is currently the needing to be renamed fetchop
> driver to take a whole granule when there are no remaining pages
> in the uncached drivers space, doing the flushes, sync.i, srlz.i
> sequences to ensure all cache lines are flushed and then shoot down
> the existing TLB entries before adding the pages of the granule to
> the uncached drivers space.  This sounds similar to what is being
> proposed here, I believe.
>
> Thanks,
> Robin

The situation I'm working with requires atleast 8MB of contiguous
memory to maintain a dirty bit map. Sometimes only the first 4k
of that bitmap may be updated/read&cleared and other times all
8MB. On 8-way and beyond systems access to dirty bitmap may degrade
performance due to coherency if the width of the locality is small,
then  I think it makes sense to change to uncached. On the other hand if
 some threshold is crossed where spatial locality width compensates
for coherency overhead then the block should be switched to
cached attribute. At this point the threshold is unknown. I was
under the impression that I could via alloc_bootmem() grab a
contiguous peiece of memory which can be accessed via
reg6 & reg7. When switching from uncachable to cachable
all activity to the dirty bit map would be halted (via locks in
cacheble memory, application controlled) and the procedure
David pointed to in the Sys Arch document can be applied (except
physical PTE part) the locks released and accesses would be
done via reg6. But now that I look at it, it seems that TRs  pin the
kernel as well with cacheble attribute.

- Mario.

Re: cacheble to uncachble change

[David Mosberger]

>>>>> On Wed, 28 Apr 2004 10:52:58 -0500, Mario Smarduch <cms063@email.mot.com> said:

  Mario> But now that I look at it, it seems that TRs pin the kernel
  Mario> as well with cacheble attribute.

Yes, there are the pinned entries and, additionally, any address
that's accessed via region 7 (address 0xe000...) will get mapped by
the alternate TLB miss-handler with a granule-sized TLB entry.  The
size of a granule is given by IA64_GRANULE_SIZE and is normally 64MB
(but may be 16MB for machines that require it).

So if you map _anything_ uncachable, you need to reserve the _entire_
(naturally-aligned) granule (all 64/16MB of it) and then you'll be OK.

	--david

RE: cacheble to uncachble change

[Smarduch Mario-CMS063]

David, thanks for answering my implicit question.

- Mario

-----Original Message-----
From: David Mosberger [mailto:davidm@napali.hpl.hp.com] 
Sent: Wednesday, April 28, 2004 11:50 PM
To: Smarduch Mario-CMS063
Cc: Robin Holt; Smarduch Mario-CMS063; davidm@hpl.hp.com; Jack Steiner; IA-64 Mailing List (New)
Subject: Re: cacheble to uncachble change


>>>>> On Wed, 28 Apr 2004 10:52:58 -0500, Mario Smarduch 
>>>>> <cms063@email.mot.com> said:

  Mario> But now that I look at it, it seems that TRs pin the kernel
  Mario> as well with cacheble attribute.

Yes, there are the pinned entries and, additionally, any address that's accessed via region 7 (address 0xe000...) will get mapped by the alternate TLB miss-handler with a granule-sized TLB entry.  The size of a granule is given by IA64_GRANULE_SIZE and is normally 64MB (but may be 16MB for machines that require it).

So if you map _anything_ uncachable, you need to reserve the _entire_
(naturally-aligned) granule (all 64/16MB of it) and then you'll be OK.

	--david