This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mlock in cache


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@redhat.com
<mailto:aph@redhat.com>> wrote:
  >>On 08/02/2013 06:06 PM, Christos Tsopokis wrote:
  >On Fri, Aug 2, 2013 at 8:09 PM, Andrew Haley <aph@redhat.com
<mailto:aph@redhat.com>> 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 Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]