Re: mlock in cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/02/2013 09:29 PM, Andrew Haley wrote:
On 08/02/2013 09:02 PM, Christos wrote:
  >>> On Fri, Aug 2, 2013 at 5:32 PM, Andrew Haley <aph@xxxxxxxxxx
<mailto:aph@xxxxxxxxxx>> wrote:
  >>On 08/02/2013 06:06 PM, Christos Tsopokis wrote:
  >On Fri, Aug 2, 2013 at 8:09 PM, Andrew Haley <aph@xxxxxxxxxx
<mailto:aph@xxxxxxxxxx>> wrote:
  >>
  >>> And why do you think that there must be a way to achieve it?  If it
  >>> exists, it's in that manual.
  >>
  >> Well, it's obviously more complicated than that. When I refer to APIs, I
  >> refer even to the information the manufacturers provide.

  >Indeed, that's what that manual I provided is.

Exactly, and because the manufacturers do not provide some instructions
for something like that (at least I didn't manage to find one), then you
have to play directly with MMU. ;-)
And how do you propose to play directly with MMU?  In a way that isn't
described in the manual?

Actually, if I was to suggest something concrete I would have such a thorough knowledge of the system that I wouldn't ask the question from the very beginning. So for me it's a topic for my research...
  >Again, I don't believe that what you seek exists, and I can think
  >of good reasons why it doesn't.

If you look carefully Oleg's answer (or even in the link I provided a
few hours ago) you will see that in some architectures it does exist.
Sure, but I'm talking about readily-available CPUs that you might have
in your desktop computer.  Were you not?
Your point is correct as my initial question was rather specific because I was asking for gcc particularly. Actually I tried to see if there was a way to do so using some C libraries (although I program many years in C and I knew it was not possible, I got into the temptation to make a quick look). The second step was to check what can be done at compiler level (that's why I mailed here). It ended up as an architecture specific issue and as such there will be multiple answers, architecture dependent.

As for gcc the main aspect that seems to be cleared out, is that compiler level prefetching does not force the cpu to do so. As I mentioned before: the directive does not really force the cpu to cache (for the same reason as before -- restricted exposure of cache internals by manufacturers), instead it works as a suggestive measure (of course with high probability of success). I suppose that only in conditions of abnormality or if the working set algorithm enforces some cache transfers, it is possible to see prefetching to fail.

Cheers

--
Christos Tsopokis





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux