From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6A6AB2007E7E2 for ; Tue, 1 May 2018 20:34:07 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id z6-v6so11919691iti.4 for ; Tue, 01 May 2018 20:34:07 -0700 (PDT) MIME-Version: 1.0 References: <152520750404.36522.15462513519590065300.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Linus Torvalds Date: Wed, 02 May 2018 03:33:55 +0000 Message-ID: Subject: Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter() List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Tony Luck , "linux-nvdimm@lists.01.org" , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andy Lutomirski , Ingo Molnar , Borislav Petkov , Al Viro , Thomas Gleixner , Andrew Morton List-ID: On Tue, May 1, 2018 at 8:22 PM Dan Williams wrote: > All that to say that having a typical RAM page covering poisoned pmem > would complicate the 'clear badblocks' implementation. Ugh, ok. I guess the good news is that your patches aren't so big, and don't really affect anything else. But can we at least take this to be the impetus for just getting rid of that disgusting unrolled memcpy? Ablout half of the lines in the patch set comes from that thing. Is anybody seriously going to use pmem with some in-order chip that can't even get something as simple as a memory copy loop right? "git blame" fingers Tony Luck, I think he may have been influenced by the fumes from Itanium. I have some dim memory of "rep movs doesn't work well for pmem", but does it *seriously* need unrolling to cacheline boundaries? And if it does, who designed it, and why is anybody using it? Linus _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751286AbeEBDeI (ORCPT ); Tue, 1 May 2018 23:34:08 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:53861 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbeEBDeH (ORCPT ); Tue, 1 May 2018 23:34:07 -0400 X-Google-Smtp-Source: AB8JxZp4OhbLRvBhv9rz9r3Pu8hKEDTqLyl8YXqGc2vofKg5xVAXgByzGB1LmrioiveVu6jUHX8DKXHnBgFP4zqNHGY= MIME-Version: 1.0 References: <152520750404.36522.15462513519590065300.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Linus Torvalds Date: Wed, 02 May 2018 03:33:55 +0000 Message-ID: Subject: Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter() To: Dan Williams Cc: "linux-nvdimm@lists.01.org" , Tony Luck , Peter Zijlstra , Borislav Petkov , "the arch/x86 maintainers" , Thomas Gleixner , Andy Lutomirski , Ingo Molnar , Al Viro , Andrew Morton , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 1, 2018 at 8:22 PM Dan Williams wrote: > All that to say that having a typical RAM page covering poisoned pmem > would complicate the 'clear badblocks' implementation. Ugh, ok. I guess the good news is that your patches aren't so big, and don't really affect anything else. But can we at least take this to be the impetus for just getting rid of that disgusting unrolled memcpy? Ablout half of the lines in the patch set comes from that thing. Is anybody seriously going to use pmem with some in-order chip that can't even get something as simple as a memory copy loop right? "git blame" fingers Tony Luck, I think he may have been influenced by the fumes from Itanium. I have some dim memory of "rep movs doesn't work well for pmem", but does it *seriously* need unrolling to cacheline boundaries? And if it does, who designed it, and why is anybody using it? Linus