Asynchronous DRAM Self-Refresh

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?

Are you certain disk was mentioned? The wording at

http://www.intel.com/design/intarch/iastorage/xeon.htm

"to preserve critical data in RAM during a power fail"
implies not. I assume there's a battery backup for
just that memory region, and the chip does its own refresh
rather than needing a controller; the data should still
be recoverable on next boot.
--
Cheers,
Jeremy

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/23/2015 10:49 AM, Jeremy Harris wrote:

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?

Are you certain disk was mentioned? The wording at

http://www.intel.com/design/intarch/iastorage/xeon.htm

"to preserve critical data in RAM during a power fail"
implies not. I assume there's a battery backup for
just that memory region, and the chip does its own refresh
rather than needing a controller; the data should still
be recoverable on next boot.

No, I'm not at all certain; like I said, I've had difficulty finding
documentation on the feature.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers