lkml.org 
[lkml]   [2018]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v12 02/11] mm, swap: Add infrastructure for saving page metadata on swap
From
Date
On 03/05/2018 12:35 PM, Dave Hansen wrote:
> On 03/05/2018 11:29 AM, Khalid Aziz wrote:
>> ADI data is per page data and is held in the spare bits in the RAM. It
>> is loaded into the cache when data is loaded from RAM and flushed out to
>> spare bits in the RAM when data is flushed from cache. Sparc allows one
>> tag for each ADI block size of data and ADI block size is same as
>> cacheline size.
>
> Which does not square with your earlier assertion "ADI data is per page
> data". It's per-cacheline data. Right?

That is one way to look at it. Current sparc processors do implement
same ADI block size as cacheline size but architecture does not require
ADI block size to be same as cacheline size. If those two sizes were
different, we wouldn't call it cacheline data.

>
>> When a page is loaded into RAM from swap space, all of
>> the associated ADI data for the page must also be loaded into the RAM,
>> so it looks like page level data and storing it in page level software
>> data structure makes sense. I am open to other suggestions though.
>
> Do you have a way to tell that data is not being thrown away? Like if
> the ADI metadata is different for two different cachelines within a
> single page?

Yes, since access to tagged data is made using pointers with ADI tag
embedded in the top bits, any mismatch between what app thinks the ADI
tags should be and what is stored in the RAM for corresponding page will
result in exception. If ADI data gets thrown away, we will get an ADI
tag mismatch exception. If ADI tags for two different ADI blocks on a
page are different when app expected them to be the same, we will see an
exception on access to the block with wrong ADI data.

--
Khalid

\
 
 \ /
  Last update: 2018-03-05 21:34    [W:0.084 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site