linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* modify the cache-inhibit and guard bits from userspace?
@ 2005-11-15 21:16 Christopher Friesen
  2005-11-15 22:38 ` Arnd Bergmann
  0 siblings, 1 reply; 3+ messages in thread
From: Christopher Friesen @ 2005-11-15 21:16 UTC (permalink / raw)
  To: linuxppc64-dev, linuxppc-embedded


We're running a dual-970 blade, based on a modified 2.6.10.

We have an application that does lots of random data fetches over a 
fairly large data set (a few GB) contained entirely in RAM, and the 
performance guys think that we may be spending time in unnecessary 
hardware prefetches and would like me to provide them a mechanism to 
individually specify the cache-inhibited and guard bits from userspace 
so that they can try to fine-tune their performance.

What's the most logical way for me to do this?  Do I extend mprotect() 
to support additional flags?

Has anyone done this before?  I didn't find anything in google. 
Currently the guard bit seems to only be used for ioremap() and in 
__pci_mmap_set_pgprot() if the memory doesn't support write combining.

Thanks,

Chris

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: modify the cache-inhibit and guard bits from userspace?
  2005-11-15 21:16 modify the cache-inhibit and guard bits from userspace? Christopher Friesen
@ 2005-11-15 22:38 ` Arnd Bergmann
  2005-11-15 23:15   ` Christopher Friesen
  0 siblings, 1 reply; 3+ messages in thread
From: Arnd Bergmann @ 2005-11-15 22:38 UTC (permalink / raw)
  To: linuxppc64-dev; +Cc: Christopher Friesen, linuxppc-embedded

Am Dienstag 15 November 2005 22:16 schrieb Christopher Friesen:
> What's the most logical way for me to do this? =A0Do I extend mprotect()
> to support additional flags?
>
> Has anyone done this before? =A0I didn't find anything in google.
> Currently the guard bit seems to only be used for ioremap() and in
> __pci_mmap_set_pgprot() if the memory doesn't support write combining.

I have seen an earlier patch that modifies madvise to do this, which seems
a little saner than mprotect, although they can probably both be implemented
in a similar way.

Alternatively, you could write a new file system similar to hugetlbfs and s=
et=20
the cache-inhibit bit in its mmap function.

	Arnd <><

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: modify the cache-inhibit and guard bits from userspace?
  2005-11-15 22:38 ` Arnd Bergmann
@ 2005-11-15 23:15   ` Christopher Friesen
  0 siblings, 0 replies; 3+ messages in thread
From: Christopher Friesen @ 2005-11-15 23:15 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc64-dev, linuxppc-embedded

Arnd Bergmann wrote:

> I have seen an earlier patch that modifies madvise to do this, which seems
> a little saner than mprotect, although they can probably both be implemented
> in a similar way.

Ah, that would make sense.  It does fit the intent of the function a bit 
better.

> Alternatively, you could write a new file system similar to hugetlbfs and set 
> the cache-inhibit bit in its mmap function.

Also a possibility.  I think the madvise method is a bit cleaner for the 
apps.

Chris

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-11-15 23:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-15 21:16 modify the cache-inhibit and guard bits from userspace? Christopher Friesen
2005-11-15 22:38 ` Arnd Bergmann
2005-11-15 23:15   ` Christopher Friesen

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).