lkml.org 
[lkml]   [2017]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
From
Date
On 01/06/2017 09:55 AM, Dave Hansen wrote:
> On 01/06/2017 08:22 AM, Khalid Aziz wrote:
>> On 01/06/2017 08:36 AM, Dave Hansen wrote:
>>> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>>>> I agree with you on simplicity first. Subpage granularity is complex,
>>>> but the architecture allows for subpage granularity. Maybe the right
>>>> approach is to support this at page granularity first for swappable
>>>> pages and then expand to subpage granularity in a subsequent patch?
>>>> Pages locked in memory can already use subpage granularity with my
>>>> patch.
>>>
>>> What do you mean by "locked in memory"? mlock()'d memory can still be
>>> migrated around and still requires "swap" ptes, for instance.
>>
>> You are right. Page migration can invalidate subpage granularity even
>> for locked pages. Is it possible to use cpusets to keep a task and its
>> memory locked on a single node?
>
> It's going to be hard to impossible to guarantee. mlock() doesn't
> guarantee that things won't change physical addresses. You'd have to
> change that guarantee or chase all the things in the kernel that might
> change physical addresses (compaction, ksm, etc...).
>
> Actually, that reminds me... How does your code interface with ksm? Or
> is there no interaction needed since you're always working on virtual
> addresses?
>

Yes, version tags are interpreted at virtual address level.

--
Khalid

\
 
 \ /
  Last update: 2017-01-06 18:10    [W:0.101 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site