From: Khalid Aziz <khalid.aziz@oracle.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
Rob Gardner <rob.gardner@oracle.com>,
davem@davemloft.net, corbet@lwn.net, arnd@arndb.de,
akpm@linux-foundation.org
Cc: hpa@zytor.com, viro@zeniv.linux.org.uk, nitin.m.gupta@oracle.com,
chris.hyser@oracle.com, tushar.n.dave@oracle.com,
sowmini.varadhan@oracle.com, mike.kravetz@oracle.com,
adam.buchbinder@gmail.com, minchan@kernel.org, hughd@google.com,
kirill.shutemov@linux.intel.com, keescook@chromium.org,
allen.pais@oracle.com, aryabinin@virtuozzo.com,
atish.patra@oracle.com, joe@perches.com, pmladek@suse.com,
jslaby@suse.cz, cmetcalf@mellanox.com,
paul.gortmaker@windriver.com, mhocko@suse.com,
jmarchan@redhat.com, lstoakes@gmail.com, 0x7f454c46@gmail.com,
vbabka@suse.cz, tglx@linutronix.de, mingo@redhat.com,
dan.j.williams@intel.com, iamjoonsoo.kim@lge.com,
mgorman@techsingularity.net, vdavydov.dev@gmail.com,
hannes@cmpxchg.org, namit@vmware.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
Khalid Aziz <khalid@gonehiking.org>
Subject: Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
Date: Thu, 5 Jan 2017 13:30:10 -0700 [thread overview]
Message-ID: <7fbc4ca1-22ef-8ef5-5c1b-dd075852e512@oracle.com> (raw)
In-Reply-To: <75c31c99-cff7-72dc-f593-012fe5acd405@linux.intel.com>
On 01/05/2017 12:22 PM, Dave Hansen wrote:
> On 01/04/2017 04:26 PM, Khalid Aziz wrote:
> ...
>> No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte.
>> There is enough space for just one tag per page. DaveM had suggested
>> doing this since the usual case is for a task to set one tag per page
>> even though MMU does not require it. I have implemented this as first
>> pass to start a discussion and get feedback on whether rest of the
>> swapping implementation and other changes look right, hence the patch is
>> "RFC". If this all looks good, I can expand swapping support in a
>> subsequent patch or iteration of this patch to allocate space in
>> mm_context_t possibly to store per cacheline tags. I am open to any
>> other ideas on storing this larger number of version tags.
>
> FWIW, This is the kind of thing that would be really useful to point out
> to reviewers instead of requiring them to ferret it out of the code. It
> has huge implications for how applications use this feature.
Hi Dave,
Thanks for taking the time to review this. I appreciate your patience. I
will add more details.
>
> As for where to store the tags... It's potentially a *lot* of data, so
> I think it'll be a pain any way you do it.
>
> If you, instead, can live with doing things on a PAGE_SIZE granularity
> like pkeys does, you could just store it in the VMA and have the kernel
> tag the data at the same time it zeroes the pages.
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. There can be 128 4-bit tags per 8K page which
requires 64 bytes of tag storage for each page. This can add up. What I
am considering doing is store the tag in swp pte if I find only one tag
on the page. A VMA can cover multiple pages and we have unused bits in
swp pte. It makes more sense to store the tags in swp pte. If I find
more than one tag on the page, I can allocate memory, attach it to a
data structure in mm_context_t and store the tags there. I will need to
use an rb tree or some other way to keep the data sorted to make it
quick to retrieve the tags for one of the millions of pages a task might
have. As I said, it gets complex trying to store tags per cacheline as
opposed to per page :)
--
Khalid
next prev parent reply other threads:[~2017-01-05 20:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 22:46 [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI) Khalid Aziz
2017-01-04 23:27 ` Dave Hansen
2017-01-04 23:35 ` Rob Gardner
2017-01-04 23:40 ` Dave Hansen
2017-01-04 23:44 ` Rob Gardner
2017-01-04 23:49 ` Dave Hansen
2017-01-04 23:56 ` Rob Gardner
2017-01-04 23:58 ` Khalid Aziz
2017-01-05 0:01 ` Dave Hansen
2017-01-05 0:05 ` Rob Gardner
2017-01-05 0:14 ` Dave Hansen
2017-01-05 0:26 ` Khalid Aziz
2017-01-05 19:22 ` Dave Hansen
2017-01-05 20:30 ` Khalid Aziz [this message]
2017-01-06 9:19 ` Michal Hocko
2017-01-06 15:32 ` Khalid Aziz
2017-01-06 15:36 ` Dave Hansen
2017-01-06 16:22 ` Khalid Aziz
2017-01-06 16:25 ` David Miller
2017-01-06 16:55 ` Dave Hansen
2017-01-06 17:02 ` David Miller
2017-01-06 17:10 ` Khalid Aziz
2017-01-06 17:54 ` Rob Gardner
2017-01-06 18:18 ` Khalid Aziz
2017-01-06 18:28 ` Rob Gardner
2017-01-06 17:08 ` Khalid Aziz
2017-01-04 23:43 ` Khalid Aziz
2017-01-04 23:31 ` Dave Hansen
2017-01-04 23:46 ` Khalid Aziz
2017-01-04 23:50 ` Dave Hansen
2017-01-05 9:37 ` Jerome Marchand
2017-01-05 15:13 ` Khalid Aziz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7fbc4ca1-22ef-8ef5-5c1b-dd075852e512@oracle.com \
--to=khalid.aziz@oracle.com \
--cc=0x7f454c46@gmail.com \
--cc=adam.buchbinder@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=allen.pais@oracle.com \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=atish.patra@oracle.com \
--cc=chris.hyser@oracle.com \
--cc=cmetcalf@mellanox.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jmarchan@redhat.com \
--cc=joe@perches.com \
--cc=jslaby@suse.cz \
--cc=keescook@chromium.org \
--cc=khalid@gonehiking.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=nitin.m.gupta@oracle.com \
--cc=paul.gortmaker@windriver.com \
--cc=pmladek@suse.com \
--cc=rob.gardner@oracle.com \
--cc=sowmini.varadhan@oracle.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tushar.n.dave@oracle.com \
--cc=vbabka@suse.cz \
--cc=vdavydov.dev@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).