Re: Asynchronous DRAM Self-Refresh - Mailing list pgsql-hackers

From Jeremy Harris
Subject Re: Asynchronous DRAM Self-Refresh
Date
Msg-id 5560C182.30602@wizmail.org
Whole thread Raw
In response to Asynchronous DRAM Self-Refresh  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 22/05/15 22:30, Josh Berkus wrote:
> At CoreOS Fest, Intel presented about a technology which they used to
> improve write times for the nonrelational data store Etcd.  It's called
> Asynchronous DRAM Self-Refresh, or ADR.  This is supposedly a feature of
> all of their chips since E5 which allows users to designate a small area
> of memory (16 to 64MB) which is somehow guaranteed to be flushed to disk
> in the event of a power loss (the exact mechanism was not explained).
> 
> So my thought was "Hello!  wal_buffers?"  Theoretically, this feature
> could give us the benefits of aynchronous commit without the penalties
> ... *if* it actually works.
> 
> However, since then I've been able to find zero documentation on ADR.
> There's a bunch of stuff in the Intel press releases, but zero I can
> find in their technical docs.  Anyone have a clue on this?
> 

http://snia.org/sites/default/files/NVDIMM%20Messaging%20and%20FAQ%20Jan%2020143.pdf

describes it as a (minor) processor feature to flush
memory-pipeline buffers to RAM on powerloss detection.
The context there is for a flash-backup on-DIMM for the
RAM.

It's unclear whether any dirty data in cpu cache gets written...
Are Intel caches never write-behind?



pgsql-hackers by date:

Previous
From: Jeremy Harris
Date:
Subject: Re: Asynchronous DRAM Self-Refresh
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound.