On 01/06/2017 10:18 AM, Khalid Aziz wrote:
On 01/06/2017 10:54 AM, Rob Gardner wrote:
On 01/06/2017 09:10 AM, Khalid Aziz wrote:
On 01/06/2017 10:02 AM, David Miller wrote:
From: Dave Hansen
Date: Fri, 6 Jan 2017 08:55:03 -0800
Actually, that reminds me... How does your code interface with
On 01/06/2017 10:54 AM, Rob Gardner wrote:
On 01/06/2017 09:10 AM, Khalid Aziz wrote:
On 01/06/2017 10:02 AM, David Miller wrote:
From: Dave Hansen
Date: Fri, 6 Jan 2017 08:55:03 -0800
Actually, that reminds me... How does your code interface with
ksm? Or
is there no interaction needed sin
On 01/06/2017 09:10 AM, Khalid Aziz wrote:
On 01/06/2017 10:02 AM, David Miller wrote:
From: Dave Hansen
Date: Fri, 6 Jan 2017 08:55:03 -0800
Actually, that reminds me... How does your code interface with
ksm? Or
is there no interaction needed since you're always working on virtual
address
On 01/06/2017 10:02 AM, David Miller wrote:
From: Dave Hansen
Date: Fri, 6 Jan 2017 08:55:03 -0800
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?
This reminds me, I consider this featur
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.
From: Dave Hansen
Date: Fri, 6 Jan 2017 08:55:03 -0800
> 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?
This reminds me, I consider this feature potentially extremely useful for
kernel
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
From: Khalid Aziz
Date: Fri, 6 Jan 2017 09:22:13 -0700
> 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
>>>
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
pag
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 granular
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 mul
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 g
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
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
On 01/05/2017 02:37 AM, Jerome Marchand wrote:
On 01/04/2017 11:46 PM, Khalid Aziz wrote:
ADI is a new feature supported on sparc M7 and newer processors to allow
hardware to catch rogue accesses to memory. ADI is supported for data
fetches only and not instruction fetches. An app can enable ADI
On 01/04/2017 11:46 PM, Khalid Aziz wrote:
> ADI is a new feature supported on sparc M7 and newer processors to allow
> hardware to catch rogue accesses to memory. ADI is supported for data
> fetches only and not instruction fetches. An app can enable ADI on its
> data pages, set version tags on th
On 01/04/2017 05:14 PM, Dave Hansen wrote:
On 01/04/2017 04:05 PM, Rob Gardner wrote:
What if two different small pages have different tags and khugepaged
comes along and tries to collapse them? Will the page be split if a
user attempts to set two different tags inside two different small-page
On 01/04/2017 04:05 PM, Rob Gardner wrote:
>> What if two different small pages have different tags and khugepaged
>> comes along and tries to collapse them? Will the page be split if a
>> user attempts to set two different tags inside two different small-page
>> portions of a single THP?
>
> The
On 01/04/2017 04:01 PM, Dave Hansen wrote:
On 01/04/2017 03:58 PM, Khalid Aziz wrote:
How does this all work with large pages?
It works with large pages the same way as normal sized pages. The TTE
for a large page also will have the mcd bit set in it and tags are set
and referenced the same way
On 01/04/2017 03:58 PM, Khalid Aziz wrote:
>> How does this all work with large pages?
>
> It works with large pages the same way as normal sized pages. The TTE
> for a large page also will have the mcd bit set in it and tags are set
> and referenced the same way.
But does the user setting the ta
On 01/04/2017 04:49 PM, Dave Hansen wrote:
On 01/04/2017 03:44 PM, Rob Gardner wrote:
On 01/04/2017 03:40 PM, Dave Hansen wrote:
On 01/04/2017 03:35 PM, Rob Gardner wrote:
Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.
On 01/04/2017 03:49 PM, Dave Hansen wrote:
On 01/04/2017 03:44 PM, Rob Gardner wrote:
On 01/04/2017 03:40 PM, Dave Hansen wrote:
On 01/04/2017 03:35 PM, Rob Gardner wrote:
Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.
On 01/04/2017 03:46 PM, Khalid Aziz wrote:
>> It would also be really nice to see a high-level breakdown explaining
>> what you had to modify, especially since this affects all of the system
>> calls that take a PROT_* argument. The sample code is nice, but it's no
>> substitute for writing it dow
On 01/04/2017 03:44 PM, Rob Gardner wrote:
> On 01/04/2017 03:40 PM, Dave Hansen wrote:
>> On 01/04/2017 03:35 PM, Rob Gardner wrote:
>>> Tags are not cleared at all when memory is freed, but rather, lazily
>>> (and automatically) cleared when memory is allocated.
>> What does "allocated" mean in t
On 01/04/2017 04:31 PM, Dave Hansen wrote:
One other high-level comment: It would be nice to see the
arch-independent and x86 portions broken out and explained in their own
right, even if they're small patches. It's a bit cruel to make us
scroll through a thousand lines of sparc code to see the
On 01/04/2017 04:27 PM, Dave Hansen wrote:
On 01/04/2017 02:46 PM, Khalid Aziz wrote:
This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable
MCD (Memory Corruption Detection) on selected memory ranges, enable
TTE.mcd in PTEs, return ADI parameters to userspace and save/restore A
On 01/04/2017 03:40 PM, Dave Hansen wrote:
On 01/04/2017 03:35 PM, Rob Gardner wrote:
Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.
What does "allocated" mean in this context? Physical or virtual? What
does this do, f
On 01/04/2017 03:35 PM, Rob Gardner wrote:
> Tags are not cleared at all when memory is freed, but rather, lazily
> (and automatically) cleared when memory is allocated.
What does "allocated" mean in this context? Physical or virtual? What
does this do, for instance?
ptr = malloc(PAGE_SI
On 01/04/2017 03:27 PM, Dave Hansen wrote:
On 01/04/2017 02:46 PM, Khalid Aziz wrote:
This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable
MCD (Memory Corruption Detection) on selected memory ranges, enable
TTE.mcd in PTEs, return ADI parameters to userspace and save/restore A
One other high-level comment: It would be nice to see the
arch-independent and x86 portions broken out and explained in their own
right, even if they're small patches. It's a bit cruel to make us
scroll through a thousand lines of sparc code to see the bits
interesting to us.
It would also be re
On 01/04/2017 02:46 PM, Khalid Aziz wrote:
> This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable
> MCD (Memory Corruption Detection) on selected memory ranges, enable
> TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI
> version tags on page swap out/in.
31 matches
Mail list logo
