This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: mlock in cache
- From: Brian Budge <brian dot budge at gmail dot com>
- To: Christos <xristos dot tsop at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GCC-help <gcc-help at gcc dot gnu dot org>, Andrew Haley <aph at redhat dot com>
- Date: Fri, 2 Aug 2013 09:38:07 -0700
- Subject: Re: mlock in cache
- References: <51FBBE65 dot 2000406 at gmail dot com> <51FBC1DE dot 3000501 at redhat dot com> <51FBCA48 dot 20106 at gmail dot com> <51FBCE48 dot 6080402 at redhat dot com> <51FBD281 dot 2040803 at gmail dot com> <51FBD309 dot 7000204 at redhat dot com> <51FBD595 dot 4020703 at gmail dot com>
On Fri, Aug 2, 2013 at 8:51 AM, Christos <xristos.tsop@gmail.com> wrote:
> On 08/02/2013 04:40 PM, Florian Weimer wrote:
>>
>> On 08/02/2013 05:38 PM, Christos wrote:
>>>
>>> On 08/02/2013 04:20 PM, Florian Weimer wrote:
>>>>
>>>> Most CPUs just do not support this.
>>>>
>>>> Some hardware transaction memory implementations perform cache line
>>>> locking as an implementation detail.
>>>
>>>
>>> Do you know any of them as an example?
>>
>>
>> Intel Haswell, perhaps.
>>
>
> Well I'll search through it but for example in arm architecture there is
> this:
> http://sourceware.org/sid/component-docs/hw-cache.html#behavior-line%20locking
>
> What I'm thinking of is if prefetching works like a force just as a
> suggestion to the cpu to cache some page. Because if it's the latter then
> you can't rely on repetitive prefetching to achieve it...
>
> --
> Christos Tsopokis
>
Can I naively ask what the purpose is of forcing this data to be in
cache all the time? If you use the data often enough for this to be
useful, it will already be in cache. If you don't, you benefit by
having it not be in cache.
Brian