Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754501AbcJGSDp (ORCPT ); Fri, 7 Oct 2016 14:03:45 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:35936 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754394AbcJGSCe (ORCPT ); Fri, 7 Oct 2016 14:02:34 -0400 MIME-Version: 1.0 In-Reply-To: <20161007173957.GA37192@kernel.org> References: <20161007003850.GA7197@kernel.org> <20161007173957.GA37192@kernel.org> From: Linus Torvalds Date: Fri, 7 Oct 2016 11:02:32 -0700 X-Google-Sender-Auth: JxdO9WkbfoqcMH2zVUDTSCU1q_8 Message-ID: Subject: Re: [GIT PULL] MD update for 4.9 To: Shaohua Li Cc: Doug Dumitru , Linux Kernel Mailing List , linux-raid , Neil Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1069 Lines: 24 On Fri, Oct 7, 2016 at 10:39 AM, Shaohua Li wrote: > > I did try your patch and it improved 10% in my machine, but this isn't > relevent to the pull. We can do the tunning later if necessary. I'm > hoping the intel guys can share some hints, but apparently Linus isn't a > fan for such tuning. We've had horrible experiences with prefetching in the past. We've seen microarchitectures that do really bad things when the prefetch takes a TLB miss, for example, and suddenly they stall on the prefetch, and actually slow the code down. Admittedly, most of the bad cases are probably not a big deal for streaming raid rebuild code, so it may well be that it works better there. So I'm not categorically against prefetching, but it needs to be tested across a lot of different (micro-)architectures. Right now, I guess something very specific like AVX512 means effectively just one or two microarchitectures and then it's easy to say "it always helps". The worst cases for the kernel have generally been in generic code. Linus