On 01/06/2017 02:19 AM, Michal Hocko wrote:
On Thu 05-01-17 13:30:10, Khalid Aziz wrote:
[...]
It is very tempting to restrict tags to PAGE_SIZE granularity since it makes
code noticeably simpler and that is indeed going to be the majority of
cases. Sooner or later somebody would want to use multiple tags per page
though.
I didn't get to read the patch throughly yet but I am really confused by
this statement. The api is mprotect based which makes it ineherently
PAGE_SIZE granular. How do you want to achieve cache line granularity
with this API?
And I would really vote for simplicity first... Subpage granularity
sounds way too tricky...
Hi Michal,
ADI can be enabled for subsets of a task's address space. It takes three
steps to enable ADI completely:
1. Enable the task to use ADI by setting PSTATE.mcde bit. This is the
master switch for ADI. mprotect() does this in my patch. Granularity for
this operation is entire address space for the task.
2. Set TTE.mcd bit for each page translation for the pages one wants ADI
enabled on. mprotect() does this as well in my patch. Granularity for
this operation is per page.
3. Set version tag for the addresses task wants to enable ADI on using
"stxa" instruction. This is done entirely in userspace with no
assistance or intervention needed from the kernel. Granularity for this
operation is cache line size which is 64 bytes on Sparc M7.
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.
Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
