Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1292168 > unrolled thread

Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks

Started byBorislav Petkov <bp@alien8.de>
First post2015-12-15 14:20 +0100
Last post2015-12-15 20:30 +0100
Articles 11 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-15 14:20 +0100
    Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Dan Williams <dan.j.williams@intel.com> - 2015-12-15 18:50 +0100
      RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks "Luck, Tony" <tony.luck@intel.com> - 2015-12-15 19:00 +0100
        Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-15 19:30 +0100
        Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Dan Williams <dan.j.williams@intel.com> - 2015-12-15 19:30 +0100
          Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Dan Williams <dan.j.williams@intel.com> - 2015-12-15 19:40 +0100
            Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-15 19:40 +0100
              Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-15 20:30 +0100
                RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> - 2015-12-15 21:30 +0100
                  Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Borislav Petkov <bp@alien8.de> - 2015-12-21 18:40 +0100
              RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> - 2015-12-15 20:30 +0100

#1292168 — Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks

FromBorislav Petkov <bp@alien8.de>
Date2015-12-15 14:20 +0100
SubjectRe: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks
Message-ID<qFXGi-4AF-13@gated-at.bofh.it>
On Thu, Dec 10, 2015 at 04:21:50PM -0800, Tony Luck wrote:
> Using __copy_user_nocache() as inspiration create a memory copy
> routine for use by kernel code with annotations to allow for
> recovery from machine checks.
> 
> Notes:
> 1) Unlike the original we make no attempt to copy all the bytes
>    up to the faulting address. The original achieves that by
>    re-executing the failing part as a byte-by-byte copy,
>    which will take another page fault. We don't want to have
>    a second machine check!
> 2) Likewise the return value for the original indicates exactly
>    how many bytes were not copied. Instead we provide the physical
>    address of the fault (thanks to help from do_machine_check()
> 3) Provide helpful macros to decode the return value.
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
>  arch/x86/include/asm/uaccess_64.h |  5 +++
>  arch/x86/kernel/x8664_ksyms_64.c  |  2 +
>  arch/x86/lib/copy_user_64.S       | 91 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 98 insertions(+)

...

> + * mcsafe_memcpy - Uncached memory copy with machine check exception handling
> + * Note that we only catch machine checks when reading the source addresses.
> + * Writes to target are posted and don't generate machine checks.
> + * This will force destination/source out of cache for more performance.

... and the non-temporal version is the optimal one even though we're
defaulting to copy_user_enhanced_fast_string for memcpy on modern Intel
CPUs...?

Btw, it should be also inside an ifdef if we're going to ifdef
CONFIG_MCE_KERNEL_RECOVERY everywhere else.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1292407

FromDan Williams <dan.j.williams@intel.com>
Date2015-12-15 18:50 +0100
Message-ID<qG1Tz-7mv-5@gated-at.bofh.it>
In reply to#1292168
On Tue, Dec 15, 2015 at 5:11 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Thu, Dec 10, 2015 at 04:21:50PM -0800, Tony Luck wrote:
>> Using __copy_user_nocache() as inspiration create a memory copy
>> routine for use by kernel code with annotations to allow for
>> recovery from machine checks.
>>
>> Notes:
>> 1) Unlike the original we make no attempt to copy all the bytes
>>    up to the faulting address. The original achieves that by
>>    re-executing the failing part as a byte-by-byte copy,
>>    which will take another page fault. We don't want to have
>>    a second machine check!
>> 2) Likewise the return value for the original indicates exactly
>>    how many bytes were not copied. Instead we provide the physical
>>    address of the fault (thanks to help from do_machine_check()
>> 3) Provide helpful macros to decode the return value.
>>
>> Signed-off-by: Tony Luck <tony.luck@intel.com>
>> ---
>>  arch/x86/include/asm/uaccess_64.h |  5 +++
>>  arch/x86/kernel/x8664_ksyms_64.c  |  2 +
>>  arch/x86/lib/copy_user_64.S       | 91 +++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 98 insertions(+)
>
> ...
>
>> + * mcsafe_memcpy - Uncached memory copy with machine check exception handling
>> + * Note that we only catch machine checks when reading the source addresses.
>> + * Writes to target are posted and don't generate machine checks.
>> + * This will force destination/source out of cache for more performance.
>
> ... and the non-temporal version is the optimal one even though we're
> defaulting to copy_user_enhanced_fast_string for memcpy on modern Intel
> CPUs...?

At least the pmem driver use case does not want caching of the
source-buffer since that is the raw "disk" media.  I.e. in
pmem_do_bvec() we'd use this to implement memcpy_from_pmem().
However, caching the destination-buffer may prove beneficial since
that data is likely to be consumed immediately by the thread that
submitted the i/o.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292417

From"Luck, Tony" <tony.luck@intel.com>
Date2015-12-15 19:00 +0100
Message-ID<qG23g-7pS-19@gated-at.bofh.it>
In reply to#1292407
Pj4gLi4uIGFuZCB0aGUgbm9uLXRlbXBvcmFsIHZlcnNpb24gaXMgdGhlIG9wdGltYWwgb25lIGV2
ZW4gdGhvdWdoIHdlJ3JlDQo+PiBkZWZhdWx0aW5nIHRvIGNvcHlfdXNlcl9lbmhhbmNlZF9mYXN0
X3N0cmluZyBmb3IgbWVtY3B5IG9uIG1vZGVybiBJbnRlbA0KPj4gQ1BVcy4uLj8NCg0KTXkgY3Vy
cmVudCBnZW5lcmF0aW9uIGNwdSBoYXMgYSBiaXQgb2YgYW4gaXNzdWUgd2l0aCByZWNvdmVyaW5n
IGZyb20gYQ0KbWFjaGluZSBjaGVjayBpbiBhICJyZXAgbW92IiAuLi4gc28gSSdtIHdvcmtpbmcg
d2l0aCBhIHZlcnNpb24gb2YgbWVtY3B5DQp0aGF0IHVucm9sbHMgaW50byBpbmRpdmlkdWFsIG1v
diBpbnN0cnVjdGlvbnMgZm9yIG5vdy4NCg0KPiBBdCBsZWFzdCB0aGUgcG1lbSBkcml2ZXIgdXNl
IGNhc2UgZG9lcyBub3Qgd2FudCBjYWNoaW5nIG9mIHRoZQ0KPiBzb3VyY2UtYnVmZmVyIHNpbmNl
IHRoYXQgaXMgdGhlIHJhdyAiZGlzayIgbWVkaWEuICBJLmUuIGluDQo+IHBtZW1fZG9fYnZlYygp
IHdlJ2QgdXNlIHRoaXMgdG8gaW1wbGVtZW50IG1lbWNweV9mcm9tX3BtZW0oKS4NCj4gSG93ZXZl
ciwgY2FjaGluZyB0aGUgZGVzdGluYXRpb24tYnVmZmVyIG1heSBwcm92ZSBiZW5lZmljaWFsIHNp
bmNlDQo+IHRoYXQgZGF0YSBpcyBsaWtlbHkgdG8gYmUgY29uc3VtZWQgaW1tZWRpYXRlbHkgYnkg
dGhlIHRocmVhZCB0aGF0DQo+IHN1Ym1pdHRlZCB0aGUgaS9vLg0KDQpJIGNhbiBkcm9wIHRoZSAi
bnRpIiBmcm9tIHRoZSBkZXN0aW5hdGlvbiBtb3Zlcy4gIERvZXMgIm50aSIgd29yaw0Kb24gdGhl
IGxvYWQgZnJvbSBzb3VyY2UgYWRkcmVzcyBzaWRlIHRvIGF2b2lkIGNhY2hlIGFsbG9jYXRpb24/
DQoNCk9uIGFub3RoZXIgdG9waWMgcmFpc2VkIGJ5IEJvcmlzIC4uLiBpcyB0aGVyZSBzb21lIENP
TkZJR19QTUVNKg0KdGhhdCBJIHNob3VsZCB1c2UgYXMgYSBkZXBlbmRlbmN5IHRvIGVuYWJsZSBh
bGwgdGhpcz8NCg0KLVRvbnkNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292434

FromBorislav Petkov <bp@alien8.de>
Date2015-12-15 19:30 +0100
Message-ID<qG2wi-7PJ-3@gated-at.bofh.it>
In reply to#1292417
On Tue, Dec 15, 2015 at 05:53:31PM +0000, Luck, Tony wrote:
> My current generation cpu has a bit of an issue with recovering from a
> machine check in a "rep mov" ... so I'm working with a version of memcpy
> that unrolls into individual mov instructions for now.

Ah.

> I can drop the "nti" from the destination moves.  Does "nti" work
> on the load from source address side to avoid cache allocation?

I don't think so:

+1:     movq (%rsi),%r8
+2:     movq 1*8(%rsi),%r9
+3:     movq 2*8(%rsi),%r10
+4:     movq 3*8(%rsi),%r11
...

You need to load the data into registers first because MOVNTI needs them
there as it does reg -> mem movement. That first load from memory into
registers with a normal MOV will pull the data into the cache.

Perhaps the first thing to try would be to see what slowdown normal MOVs
bring and if not really noticeable, use those instead.

> On another topic raised by Boris ... is there some CONFIG_PMEM*
> that I should use as a dependency to enable all this?

I found CONFIG_LIBNVDIMM only today:

drivers/nvdimm/Kconfig:1:menuconfig LIBNVDIMM
drivers/nvdimm/Kconfig:2:       tristate "NVDIMM (Non-Volatile Memory Device) Support"

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292438

FromDan Williams <dan.j.williams@intel.com>
Date2015-12-15 19:30 +0100
Message-ID<qG2wi-7PJ-5@gated-at.bofh.it>
In reply to#1292417
On Tue, Dec 15, 2015 at 9:53 AM, Luck, Tony <tony.luck@intel.com> wrote:
>>> ... and the non-temporal version is the optimal one even though we're
>>> defaulting to copy_user_enhanced_fast_string for memcpy on modern Intel
>>> CPUs...?
>
> My current generation cpu has a bit of an issue with recovering from a
> machine check in a "rep mov" ... so I'm working with a version of memcpy
> that unrolls into individual mov instructions for now.
>
>> At least the pmem driver use case does not want caching of the
>> source-buffer since that is the raw "disk" media.  I.e. in
>> pmem_do_bvec() we'd use this to implement memcpy_from_pmem().
>> However, caching the destination-buffer may prove beneficial since
>> that data is likely to be consumed immediately by the thread that
>> submitted the i/o.
>
> I can drop the "nti" from the destination moves.  Does "nti" work
> on the load from source address side to avoid cache allocation?

My mistake, I don't think we have an uncached load capability, only store.

> On another topic raised by Boris ... is there some CONFIG_PMEM*
> that I should use as a dependency to enable all this?

I'd rather make this a "select ARCH_MCSAFE_MEMCPY".  Since it's not a
hard dependency and the details will be hidden behind
memcpy_from_pmem().  Specifically, the details will be handled by a
new arch_memcpy_from_pmem() in arch/x86/include/asm/pmem.h to
supplement the existing arch_memcpy_to_pmem().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292448

FromDan Williams <dan.j.williams@intel.com>
Date2015-12-15 19:40 +0100
Message-ID<qG2FX-7U3-1@gated-at.bofh.it>
In reply to#1292438
On Tue, Dec 15, 2015 at 10:27 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Dec 15, 2015 at 9:53 AM, Luck, Tony <tony.luck@intel.com> wrote:
>>>> ... and the non-temporal version is the optimal one even though we're
>>>> defaulting to copy_user_enhanced_fast_string for memcpy on modern Intel
>>>> CPUs...?
>>
>> My current generation cpu has a bit of an issue with recovering from a
>> machine check in a "rep mov" ... so I'm working with a version of memcpy
>> that unrolls into individual mov instructions for now.
>>
>>> At least the pmem driver use case does not want caching of the
>>> source-buffer since that is the raw "disk" media.  I.e. in
>>> pmem_do_bvec() we'd use this to implement memcpy_from_pmem().
>>> However, caching the destination-buffer may prove beneficial since
>>> that data is likely to be consumed immediately by the thread that
>>> submitted the i/o.
>>
>> I can drop the "nti" from the destination moves.  Does "nti" work
>> on the load from source address side to avoid cache allocation?
>
> My mistake, I don't think we have an uncached load capability, only store.

Correction we have MOVNTDQA, but that requires saving the fpu state
and marking the memory as WC, i.e. probably not worth it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292455

FromBorislav Petkov <bp@alien8.de>
Date2015-12-15 19:40 +0100
Message-ID<qG2FY-7U3-23@gated-at.bofh.it>
In reply to#1292448
On Tue, Dec 15, 2015 at 10:35:49AM -0800, Dan Williams wrote:
> Correction we have MOVNTDQA, but that requires saving the fpu state
> and marking the memory as WC, i.e. probably not worth it.

Not really. Last time I tried an SSE3 memcpy in the kernel like glibc
does, it wasn't worth it. The enhanced REP; MOVSB is hands down faster.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292489

FromBorislav Petkov <bp@alien8.de>
Date2015-12-15 20:30 +0100
Message-ID<qG3sm-8qM-27@gated-at.bofh.it>
In reply to#1292455
On Tue, Dec 15, 2015 at 07:19:58PM +0000, Elliott, Robert (Persistent Memory) wrote:

...

> Due to the historic long latency of storage devices,
> applications don't re-read from storage again; they
> save the results.
> So, the streaming-load instructions are beneficial:

That's the theory...

Do you also have some actual performance numbers where non-temporal
operations are better than the REP; MOVSB and *actually* show
improvements? And no microbenchmarks please.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292520

From"Elliott, Robert (Persistent Memory)" <elliott@hpe.com>
Date2015-12-15 21:30 +0100
Message-ID<qG4op-Bj-1@gated-at.bofh.it>
In reply to#1292489
DQoNCi0tLQ0KUm9iZXJ0IEVsbGlvdHQsIEhQRSBQZXJzaXN0ZW50IE1lbW9yeQ0KDQoNCj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQm9yaXNsYXYgUGV0a292IFttYWlsdG86
YnBAYWxpZW44LmRlXQ0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAxNSAxOjI5IFBN
DQo+IFRvOiBFbGxpb3R0LCBSb2JlcnQgKFBlcnNpc3RlbnQgTWVtb3J5KSA8ZWxsaW90dEBocGUu
Y29tPg0KPiBDYzogRGFuIFdpbGxpYW1zIDxkYW4uai53aWxsaWFtc0BpbnRlbC5jb20+OyBMdWNr
LCBUb255DQo+IDx0b255Lmx1Y2tAaW50ZWwuY29tPjsgbGludXgtbnZkaW1tIDxsaW51eC1udmRp
bW1AbWwwMS4wMS5vcmc+OyBYODYgTUwNCj4gPHg4NkBrZXJuZWwub3JnPjsgbGludXgta2VybmVs
QHZnZXIua2VybmVsLm9yZzsgTGludXggTU0gPGxpbnV4LQ0KPiBtbUBrdmFjay5vcmc+OyBBbmR5
IEx1dG9taXJza2kgPGx1dG9Aa2VybmVsLm9yZz47IEFuZHJldyBNb3J0b24NCj4gPGFrcG1AbGlu
dXgtZm91bmRhdGlvbi5vcmc+OyBJbmdvIE1vbG5hciA8bWluZ29Aa2VybmVsLm9yZz4NCj4gU3Vi
amVjdDogUmU6IFtQQVRDSFYyIDMvM10geDg2LCByYXM6IEFkZCBtY3NhZmVfbWVtY3B5KCkgZnVu
Y3Rpb24gdG8NCj4gcmVjb3ZlciBmcm9tIG1hY2hpbmUgY2hlY2tzDQo+IA0KPiBPbiBUdWUsIERl
YyAxNSwgMjAxNSBhdCAwNzoxOTo1OFBNICswMDAwLCBFbGxpb3R0LCBSb2JlcnQgKFBlcnNpc3Rl
bnQNCj4gTWVtb3J5KSB3cm90ZToNCj4gDQo+IC4uLg0KPiANCj4gPiBEdWUgdG8gdGhlIGhpc3Rv
cmljIGxvbmcgbGF0ZW5jeSBvZiBzdG9yYWdlIGRldmljZXMsDQo+ID4gYXBwbGljYXRpb25zIGRv
bid0IHJlLXJlYWQgZnJvbSBzdG9yYWdlIGFnYWluOyB0aGV5DQo+ID4gc2F2ZSB0aGUgcmVzdWx0
cy4NCj4gPiBTbywgdGhlIHN0cmVhbWluZy1sb2FkIGluc3RydWN0aW9ucyBhcmUgYmVuZWZpY2lh
bDoNCj4gDQo+IFRoYXQncyB0aGUgdGhlb3J5Li4uDQo+IA0KPiBEbyB5b3UgYWxzbyBoYXZlIHNv
bWUgYWN0dWFsIHBlcmZvcm1hbmNlIG51bWJlcnMgd2hlcmUgbm9uLXRlbXBvcmFsDQo+IG9wZXJh
dGlvbnMgYXJlIGJldHRlciB0aGFuIHRoZSBSRVA7IE1PVlNCIGFuZCAqYWN0dWFsbHkqIHNob3cN
Cj4gaW1wcm92ZW1lbnRzPyBBbmQgbm8gbWljcm9iZW5jaG1hcmtzIHBsZWFzZS4NCj4gDQo+IFRo
YW5rcy4NCj4gDQoNClRoaXMgaXNuJ3QgZXhhY3RseSB3aGF0IHlvdSdyZSBsb29raW5nIGZvciwg
YnV0IGhlcmUgaXMgDQphbiBleGFtcGxlIG9mIGZpbyBkb2luZyByZWFkcyBmcm9tIHBtZW0gZGV2
aWNlcyAocmVhZGluZw0KZnJvbSBOVkRJTU1zLCB3cml0aW5nIHRvIERJTU1zKSB3aXRoIHZhcmlv
dXMgdHJhbnNmZXINCnNpemVzLg0KDQpBdCAyNTYgS2lCLCBhbGwgdGhlIG1haW4gbWVtb3J5IGJ1
ZmZlcnMgZml0IGluIHRoZSBDUFUNCmNhY2hlcywgc28gbm8gd3JpdGUgdHJhZmZpYyBhcHBlYXJz
IG9uIEREUiAoanVzdCB0aGUgcmVhZHMNCmZyb20gdGhlIE5WRElNTXMpLiAgQXQgMSBNaUIsIHRo
ZSBkYXRhIHNwaWxscyBvdXQgb2YgdGhlDQpjYWNoZXMsIGFuZCB3cml0ZXMgdG8gdGhlIERJTU1z
IGVuZCB1cCBvbiBERFIuDQoNCkFsdGhvdWdoIEREUiBpcyBidXNpZXIsIGZpbyBnZXRzIGEgbG90
IGxlc3Mgd29yayBkb25lOg0KKiAyNTYgS2lCOiA5MCBHaUIvcyBieSBmaW8NCiogICAxIE1pQjog
NDkgR2lCL3MgYnkgZmlvDQoNCldlIGNvdWxkIHRyeSBtb2RpZnlpbmcgcG1lbSB0byB1c2UgaXRz
IG93biBub24tdGVtcG9yYWwNCm1lbWNweSBmdW5jdGlvbnMgKEkndmUgcG9zdGVkIGV4cGVyaW1l
bnRhbCBwYXRjaGVzDQpiZWZvcmUgdGhhdCBkaWQgdGhpcykgdG8gc2VlIGlmIHRoYXQgdHJhbnNp
dGlvbiBwb2ludA0Kc2hpZnRzLiAgV2UgY2FuIGFsc28gd2F0Y2ggdGhlIENQVSBjYWNoZSBzdGF0
aXN0aWNzDQp3aGlsZSBydW5uaW5nLg0KDQpIZXJlIGFyZSBzdGF0aXN0aWNzIGZyb20gSW50ZWwn
cyBwY20tbWVtb3J5LnggDQoocGFyZG9uIHRoZSB3aWRlIGZvcm1hdHRpbmcpOg0KDQoyNTYgS2lC
DQo9PT09PT09DQpwbWVtMDogKGdyb3VwaWQ9MCwgam9icz00MCk6IGVycj0gMDogcGlkPTIwODY3
OiBUdWUgTm92IDI0IDE4OjIwOjA4IDIwMTUNCiAgcmVhZCA6IGlvPTUyMTkuMUdCLCBidz04OTA3
OU1CL3MsIGlvcHM9MzU2MzE0LCBydW50PSA2MDAwNm1zZWMNCiAgY3B1ICAgICAgICAgIDogdXNy
PTEuNzQlLCBzeXM9OTYuMTYlLCBjdHg9NDk1NzYsIG1hamY9MCwgbWluZj0yMTk5Nw0KDQpSdW4g
c3RhdHVzIGdyb3VwIDAgKGFsbCBqb2JzKToNCiAgIFJFQUQ6IGlvPTUyMTkuMUdCLCBhZ2dyYj04
OTA3OU1CL3MsIG1pbmI9ODkwNzlNQi9zLCBtYXhiPTg5MDc5TUIvcywgbWludD02MDAwNm1zZWMs
IG1heHQ9NjAwMDZtc2VjDQoNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCnwtLSAgICAgICAg
ICAgICBTb2NrZXQgIDAgICAgICAgICAgICAgLS18fC0tICAgICAgICAgICAgIFNvY2tldCAgMSAg
ICAgICAgICAgICAtLXwNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18
fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCnwtLSAgICAgTWVtb3J5
IENoYW5uZWwgTW9uaXRvcmluZyAgICAgLS18fC0tICAgICBNZW1vcnkgQ2hhbm5lbCBNb25pdG9y
aW5nICAgICAtLXwNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCnwtLSBNZW0gQ2ggIDA6IFJl
YWRzIChNQi9zKTogMTE3NzguMTEgLS18fC0tIE1lbSBDaCAgMDogUmVhZHMgKE1CL3MpOiAxMTc0
My45OSAtLXwNCnwtLSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogICAgNTEuODMgLS18fC0tICAg
ICAgICAgICAgV3JpdGVzKE1CL3MpOiAgICA0My4yNSAtLXwNCnwtLSBNZW0gQ2ggIDE6IFJlYWRz
IChNQi9zKTogMTE3NzkuOTAgLS18fC0tIE1lbSBDaCAgMTogUmVhZHMgKE1CL3MpOiAxMTczNi4w
NiAtLXwNCnwtLSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogICAgNDguNzMgLS18fC0tICAgICAg
ICAgICAgV3JpdGVzKE1CL3MpOiAgICAzNy44NiAtLXwNCnwtLSBNZW0gQ2ggIDQ6IFJlYWRzIChN
Qi9zKTogMTE3ODQuNzkgLS18fC0tIE1lbSBDaCAgNDogUmVhZHMgKE1CL3MpOiAxMTc0Ni45NCAt
LXwNCnwtLSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogICAgNTIuOTAgLS18fC0tICAgICAgICAg
ICAgV3JpdGVzKE1CL3MpOiAgICA0My43MyAtLXwNCnwtLSBNZW0gQ2ggIDU6IFJlYWRzIChNQi9z
KTogMTE3NzguNDggLS18fC0tIE1lbSBDaCAgNTogUmVhZHMgKE1CL3MpOiAxMTc0MS41NSAtLXwN
CnwtLSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogICAgNDcuNjIgLS18fC0tICAgICAgICAgICAg
V3JpdGVzKE1CL3MpOiAgICAzNy44MCAtLXwNCnwtLSBOT0RFIDAgTWVtIFJlYWQgKE1CL3MpIDog
NDcxMjEuMjcgLS18fC0tIE5PREUgMSBNZW0gUmVhZCAoTUIvcykgOiA0Njk2OC41MyAtLXwNCnwt
LSBOT0RFIDAgTWVtIFdyaXRlKE1CL3MpIDogICAyMDEuMDggLS18fC0tIE5PREUgMSBNZW0gV3Jp
dGUoTUIvcykgOiAgIDE2Mi42NSAtLXwNCnwtLSBOT0RFIDAgUC4gV3JpdGUgKFQvcyk6ICAgICAx
OTA5MjcgLS18fC0tIE5PREUgMSBQLiBXcml0ZSAoVC9zKTogICAgIDE4Mjk2MSAtLXwNCnwtLSBO
T0RFIDAgTWVtb3J5IChNQi9zKTogICAgNDczMjIuMzYgLS18fC0tIE5PREUgMSBNZW1vcnkgKE1C
L3MpOiAgICA0NzEzMS4xNyAtLXwNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCnwtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLXwNCnwtLSAgICAgICAgICAgICAgICAgICBTeXN0ZW0gUmVhZCBUaHJv
dWdocHV0KE1CL3MpOiAgOTQwODkuODAgICAgICAgICAgICAgICAgICAtLXwNCnwtLSAgICAgICAg
ICAgICAgICAgIFN5c3RlbSBXcml0ZSBUaHJvdWdocHV0KE1CL3MpOiAgICAzNjMuNzMgICAgICAg
ICAgICAgICAgICAtLXwNCnwtLSAgICAgICAgICAgICAgICAgU3lzdGVtIE1lbW9yeSBUaHJvdWdo
cHV0KE1CL3MpOiAgOTQ0NTMuNTIgICAgICAgICAgICAgICAgICAtLXwNCnwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLXwNCg0KMSBNaUINCj09PT09DQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tfHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQp8
LS0gICAgICAgICAgICAgU29ja2V0ICAwICAgICAgICAgICAgIC0tfHwtLSAgICAgICAgICAgICBT
b2NrZXQgIDEgICAgICAgICAgICAgLS18DQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tfHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQp8LS0g
ICAgIE1lbW9yeSBDaGFubmVsIE1vbml0b3JpbmcgICAgIC0tfHwtLSAgICAgTWVtb3J5IENoYW5u
ZWwgTW9uaXRvcmluZyAgICAgLS18DQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tfHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQp8LS0gTWVt
IENoICAwOiBSZWFkcyAoTUIvcyk6ICA3MjI3LjgzIC0tfHwtLSBNZW0gQ2ggIDA6IFJlYWRzIChN
Qi9zKTogIDcwNDcuNDUgLS18DQp8LS0gICAgICAgICAgICBXcml0ZXMoTUIvcyk6ICA1ODk0LjQ3
IC0tfHwtLSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogIDYwMTAuNjYgLS18DQp8LS0gTWVtIENo
ICAxOiBSZWFkcyAoTUIvcyk6ICA3MjI5LjMyIC0tfHwtLSBNZW0gQ2ggIDE6IFJlYWRzIChNQi9z
KTogIDcwNDEuNzkgLS18DQp8LS0gICAgICAgICAgICBXcml0ZXMoTUIvcyk6ICA1ODkxLjM4IC0t
fHwtLSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogIDYwMDMuMTkgLS18DQp8LS0gTWVtIENoICA0
OiBSZWFkcyAoTUIvcyk6ICA3MjMwLjcwIC0tfHwtLSBNZW0gQ2ggIDQ6IFJlYWRzIChNQi9zKTog
IDcwNTIuNDQgLS18DQp8LS0gICAgICAgICAgICBXcml0ZXMoTUIvcyk6ICA1ODg4LjYzIC0tfHwt
LSAgICAgICAgICAgIFdyaXRlcyhNQi9zKTogIDYwMTIuNDkgLS18DQp8LS0gTWVtIENoICA1OiBS
ZWFkcyAoTUIvcyk6ICA3MjI5LjE2IC0tfHwtLSBNZW0gQ2ggIDU6IFJlYWRzIChNQi9zKTogIDcw
NDcuMTkgLS18DQp8LS0gICAgICAgICAgICBXcml0ZXMoTUIvcyk6ICA1ODgyLjQ1IC0tfHwtLSAg
ICAgICAgICAgIFdyaXRlcyhNQi9zKTogIDYwMDguMTEgLS18DQp8LS0gTk9ERSAwIE1lbSBSZWFk
IChNQi9zKSA6IDI4OTE3LjAxIC0tfHwtLSBOT0RFIDEgTWVtIFJlYWQgKE1CL3MpIDogMjgxODgu
ODcgLS18DQp8LS0gTk9ERSAwIE1lbSBXcml0ZShNQi9zKSA6IDIzNTU2LjkzIC0tfHwtLSBOT0RF
IDEgTWVtIFdyaXRlKE1CL3MpIDogMjQwMzQuNDYgLS18DQp8LS0gTk9ERSAwIFAuIFdyaXRlIChU
L3MpOiAgICAgMjM4NzEzIC0tfHwtLSBOT0RFIDEgUC4gV3JpdGUgKFQvcyk6ICAgICAyMjgwNDAg
LS18DQp8LS0gTk9ERSAwIE1lbW9yeSAoTUIvcyk6ICAgIDUyNDczLjk0IC0tfHwtLSBOT0RFIDEg
TWVtb3J5IChNQi9zKTogICAgNTIyMjMuMzMgLS18DQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tfHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18
DQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfHwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQp8LS0gICAgICAgICAgICAgICAgICAgU3lzdGVt
IFJlYWQgVGhyb3VnaHB1dChNQi9zKTogIDU3MTA1Ljg3ICAgICAgICAgICAgICAgICAgLS18DQp8
LS0gICAgICAgICAgICAgICAgICBTeXN0ZW0gV3JpdGUgVGhyb3VnaHB1dChNQi9zKTogIDQ3NTkx
LjM5ICAgICAgICAgICAgICAgICAgLS18DQp8LS0gICAgICAgICAgICAgICAgIFN5c3RlbSBNZW1v
cnkgVGhyb3VnaHB1dChNQi9zKTogMTA0Njk3LjI3ICAgICAgICAgICAgICAgICAgLS18DQp8LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfHwtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS18DQoNCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296105

FromBorislav Petkov <bp@alien8.de>
Date2015-12-21 18:40 +0100
Message-ID<qIcBc-11j-17@gated-at.bofh.it>
In reply to#1292520
On Tue, Dec 15, 2015 at 08:25:37PM +0000, Elliott, Robert (Persistent Memory) wrote:
> This isn't exactly what you're looking for, but here is 
> an example of fio doing reads from pmem devices (reading
> from NVDIMMs, writing to DIMMs) with various transfer
> sizes.

... and "fio" is?

> At 256 KiB, all the main memory buffers fit in the CPU
> caches, so no write traffic appears on DDR (just the reads
> from the NVDIMMs).  At 1 MiB, the data spills out of the
> caches, and writes to the DIMMs end up on DDR.
> 
> Although DDR is busier, fio gets a lot less work done:
> * 256 KiB: 90 GiB/s by fio
> *   1 MiB: 49 GiB/s by fio

Yeah, I don't think that answers the question I had: whether REP; MOVSB
is faster/better than using non-temporal stores. But you say that
already above.

Also, if you do non-temporal stores then you're expected to have *more*
memory controller and DIMM traffic as you're pushing everything out
through the WCC.

What would need to be measured instead is, IMO, two things:

* compare NTI vs REP; MOVSB data movement to see the differences in
performance aspects

* run a benchmark (no idea which one) which would measure the positive
impact of the NTI versions which do not pollute the cache and thus do
not hurt other workloads' working set being pushed out of the cache.

Also, we don't really know (at least I don't) what REP; MOVSB
improvements hide behind those enhanced fast string optimizations.
It could be that microcode is doing some aggregation into cachelines
and doing much bigger writes which could compensate for the cache
pollution.

Questions over questions...

> We could try modifying pmem to use its own non-temporal
> memcpy functions (I've posted experimental patches
> before that did this) to see if that transition point
> shifts.  We can also watch the CPU cache statistics
> while running.
> 
> Here are statistics from Intel's pcm-memory.x 
> (pardon the wide formatting):
> 
> 256 KiB
> =======
> pmem0: (groupid=0, jobs=40): err= 0: pid=20867: Tue Nov 24 18:20:08 2015
>   read : io=5219.1GB, bw=89079MB/s, iops=356314, runt= 60006msec
>   cpu          : usr=1.74%, sys=96.16%, ctx=49576, majf=0, minf=21997
> 
> Run status group 0 (all jobs):
>    READ: io=5219.1GB, aggrb=89079MB/s, minb=89079MB/s, maxb=89079MB/s, mint=60006msec, maxt=60006msec
> 
> |---------------------------------------||---------------------------------------|
> |--             Socket  0             --||--             Socket  1             --|
> |---------------------------------------||---------------------------------------|
> |--     Memory Channel Monitoring     --||--     Memory Channel Monitoring     --|
> |---------------------------------------||---------------------------------------|
> |-- Mem Ch  0: Reads (MB/s): 11778.11 --||-- Mem Ch  0: Reads (MB/s): 11743.99 --|
> |--            Writes(MB/s):    51.83 --||--            Writes(MB/s):    43.25 --|
> |-- Mem Ch  1: Reads (MB/s): 11779.90 --||-- Mem Ch  1: Reads (MB/s): 11736.06 --|
> |--            Writes(MB/s):    48.73 --||--            Writes(MB/s):    37.86 --|
> |-- Mem Ch  4: Reads (MB/s): 11784.79 --||-- Mem Ch  4: Reads (MB/s): 11746.94 --|
> |--            Writes(MB/s):    52.90 --||--            Writes(MB/s):    43.73 --|
> |-- Mem Ch  5: Reads (MB/s): 11778.48 --||-- Mem Ch  5: Reads (MB/s): 11741.55 --|
> |--            Writes(MB/s):    47.62 --||--            Writes(MB/s):    37.80 --|
> |-- NODE 0 Mem Read (MB/s) : 47121.27 --||-- NODE 1 Mem Read (MB/s) : 46968.53 --|
> |-- NODE 0 Mem Write(MB/s) :   201.08 --||-- NODE 1 Mem Write(MB/s) :   162.65 --|
> |-- NODE 0 P. Write (T/s):     190927 --||-- NODE 1 P. Write (T/s):     182961 --|

What does T/s mean?

> |-- NODE 0 Memory (MB/s):    47322.36 --||-- NODE 1 Memory (MB/s):    47131.17 --|
> |---------------------------------------||---------------------------------------|
> |---------------------------------------||---------------------------------------|
> |--                   System Read Throughput(MB/s):  94089.80                  --|
> |--                  System Write Throughput(MB/s):    363.73                  --|
> |--                 System Memory Throughput(MB/s):  94453.52                  --|
> |---------------------------------------||---------------------------------------|
> 
> 1 MiB
> =====
> |---------------------------------------||---------------------------------------|
> |--             Socket  0             --||--             Socket  1             --|
> |---------------------------------------||---------------------------------------|
> |--     Memory Channel Monitoring     --||--     Memory Channel Monitoring     --|
> |---------------------------------------||---------------------------------------|
> |-- Mem Ch  0: Reads (MB/s):  7227.83 --||-- Mem Ch  0: Reads (MB/s):  7047.45 --|
> |--            Writes(MB/s):  5894.47 --||--            Writes(MB/s):  6010.66 --|
> |-- Mem Ch  1: Reads (MB/s):  7229.32 --||-- Mem Ch  1: Reads (MB/s):  7041.79 --|
> |--            Writes(MB/s):  5891.38 --||--            Writes(MB/s):  6003.19 --|
> |-- Mem Ch  4: Reads (MB/s):  7230.70 --||-- Mem Ch  4: Reads (MB/s):  7052.44 --|
> |--            Writes(MB/s):  5888.63 --||--            Writes(MB/s):  6012.49 --|
> |-- Mem Ch  5: Reads (MB/s):  7229.16 --||-- Mem Ch  5: Reads (MB/s):  7047.19 --|
> |--            Writes(MB/s):  5882.45 --||--            Writes(MB/s):  6008.11 --|
> |-- NODE 0 Mem Read (MB/s) : 28917.01 --||-- NODE 1 Mem Read (MB/s) : 28188.87 --|
> |-- NODE 0 Mem Write(MB/s) : 23556.93 --||-- NODE 1 Mem Write(MB/s) : 24034.46 --|
> |-- NODE 0 P. Write (T/s):     238713 --||-- NODE 1 P. Write (T/s):     228040 --|
> |-- NODE 0 Memory (MB/s):    52473.94 --||-- NODE 1 Memory (MB/s):    52223.33 --|
> |---------------------------------------||---------------------------------------|
> |---------------------------------------||---------------------------------------|
> |--                   System Read Throughput(MB/s):  57105.87                  --|
> |--                  System Write Throughput(MB/s):  47591.39                  --|
> |--                 System Memory Throughput(MB/s): 104697.27                  --|
> |---------------------------------------||---------------------------------------|

Looks to me like, because writes have increased, the read bandwidth has
dropped too, which makes sense.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292493

From"Elliott, Robert (Persistent Memory)" <elliott@hpe.com>
Date2015-12-15 20:30 +0100
Message-ID<qG3sm-8qM-29@gated-at.bofh.it>
In reply to#1292455

> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf
> Of Borislav Petkov
> Sent: Tuesday, December 15, 2015 12:39 PM
> To: Dan Williams <dan.j.williams@intel.com>
> Cc: Luck, Tony <tony.luck@intel.com>; linux-nvdimm <linux-
> nvdimm@ml01.01.org>; X86 ML <x86@kernel.org>; linux-
> kernel@vger.kernel.org; Linux MM <linux-mm@kvack.org>; Andy Lutomirski
> <luto@kernel.org>; Andrew Morton <akpm@linux-foundation.org>; Ingo Molnar
> <mingo@kernel.org>
> Subject: Re: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to
> recover from machine checks
> 
> On Tue, Dec 15, 2015 at 10:35:49AM -0800, Dan Williams wrote:
> > Correction we have MOVNTDQA, but that requires saving the fpu state
> > and marking the memory as WC, i.e. probably not worth it.
> 
> Not really. Last time I tried an SSE3 memcpy in the kernel like glibc
> does, it wasn't worth it. The enhanced REP; MOVSB is hands down faster.

Reading from NVDIMM, rep movsb is efficient, but it 
fills the CPU caches with the NVDIMM addresses. For
large data moves (not uncommon for storage) this
will crowd out more important cacheable data.

For normal block device reads made through the pmem
block device driver, this CPU cache consumption is
wasteful, since it is unlikely the application will
ask pmem to read the same addresses anytime soon.
Due to the historic long latency of storage devices,
applications don't re-read from storage again; they
save the results.  So, the streaming-load
instructions are beneficial:
* movntdqa (16-byte xmm registers) 
* vmovntdqa (32-byte ymm registers)
* vmovntdqa (64-byte zmm registers)

Dan Williams wrote:
> Correction we have MOVNTDQA, but that requires
> saving the fpu state and marking the memory as WC
> i.e. probably not worth it.

Although the WC memory type is described in the SDM
in the most detail:
    "An implementation may also make use of the
    non-temporal hint associated with this instruction
    if the memory source is WB (write back) memory
    type. ... may optimize cache reads generated by 
    (V)MOVNTDQA on WB memory type to reduce cache 
    evictions."

For applications doing loads from mmap() DAX memory, 
the CPU cache usage could be worthwhile, because
applications expect mmap() regions to consist of
traditional writeback-cached memory and might do
lots of loads/stores.

Writing to the NVDIMM requires either:
* non-temporal stores; or
* normal stores + cache flushes + fences

movnti is OK for small transfers, but these are
better for bulk moves:
* movntdq (16-byte xmm registers)
* vmovntdq (32-byte ymm registers)
* vmovntdq (64-byte zmm registers)

---
Robert Elliott, HPE Persistent Memory

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web