Messages in this thread | | | Subject | Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI) | From | Khalid Aziz <> | Date | Fri, 6 Jan 2017 10:08:27 -0700 |
| |
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
| |