mlock in cache

Christos xristos.tsop@gmail.com
Fri Aug 2 20:42:00 GMT 2013


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



More information about the Gcc-help mailing list