Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp517207ybh; Wed, 22 Jul 2020 06:33:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwl6QBhvPZRq+E+P1kl+m4b2+TL3eNYn7Cbye1sS5TzbR3Dwr6GKdPp3iqiV33G/7jHuZQj X-Received: by 2002:a17:906:4a87:: with SMTP id x7mr28886838eju.44.1595424833868; Wed, 22 Jul 2020 06:33:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595424833; cv=none; d=google.com; s=arc-20160816; b=CdT1FZ+Cs50kwaM8DAXz2Djq8LZEWeJC88R4xZodnClm1Oo7xSb+ss+FcZuDN/l7WQ hN9LwRQh7ZY1PG1vPasDs9zIiQBecNyscZCQBh/jc/o7dTg0W6FBUhxVbiz0lEvIIsLJ 5gCJx2HkJA+0vLTuyRW/DhYF2ieZ7rmtV42P/1VGRP2AlgJSUGuLzocqI3RiEyjozChi 356+mHZOMPUVnfnx2kg77AoNtChPoX7mReqxL0kSMoL42AV0MUlAfRwyfVi2NNv6+YU4 jz6xWF3JoB+Tu9q/TW6Fq/66YhfizHk5ds+dkBaMVs6HEbtsXE336iO3Wfrk/nAEtsse QLyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:in-reply-to:date:references :message-id:organization:from:subject:cc:to:dkim-signature; bh=SGDxiMkv+K/gRs79Axes9Aq4nm/uxe/9Z6BhER1gB0Q=; b=ZF2LZxOh/7VKqz/EBnC+tERAG1yr5tklHUYJBQL0x7PT0T7qKV0chRmlZkv1SoAdxr zOiLO8zFF8fbUe+llwzCmdeNqyI3tx3LluE8H6MprkqiuNiGgemw7o1rMpRfmgszrzGA Sx1uJNiSQneYP61sMxysXyUJqvgb79YPlYduqC5bj2fCUMMkKy745x7wIg5nR0nSXw06 I/yZ2luRB64LKRfGHiT8EAEihwEMocAM6kdR9ZcekkbYLxtePpbzf6EJ2fB8cbHnIL9y mAxSij6EmCAGTzh5OmbhuMPhWJvTRfztxzj+sdirMWXpfUhCCgJAGfj1A0i7UzE3McgG TlEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=M17jaN2x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bx17si14111663edb.559.2020.07.22.06.33.29; Wed, 22 Jul 2020 06:33:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=M17jaN2x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732394AbgGVNcg (ORCPT + 99 others); Wed, 22 Jul 2020 09:32:36 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:45358 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726539AbgGVNcf (ORCPT ); Wed, 22 Jul 2020 09:32:35 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06MDBLs6026245; Wed, 22 Jul 2020 13:27:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : cc : subject : from : message-id : references : date : in-reply-to : mime-version : content-type; s=corp-2020-01-29; bh=SGDxiMkv+K/gRs79Axes9Aq4nm/uxe/9Z6BhER1gB0Q=; b=M17jaN2xoPQjyzcbNIh3EyAt4L6vYmmCoIqfNEMXNxXt0vzVBRus39mqoBEim2QS4gl0 ZEADhZS2JBt2F7fKfyR+8i2sOHwxVi7BaCCMheuAGRRXQqWB1nWcDgM5X14uo35sG05r zlijQgQbwaef/JC4O3F/g7yEqPNfaQNKx2aCWkHFu1gDe7esOn1Gkr3dq25D71GBzEPQ 6KS+bJgLAQJnq85Fp3AC5Jeo7nvKeGNeWXiAf1kbeFGXNrLprBeiotYq1hiftxnJR1QC wkrlIGy9zAxq9hiRWdKeuXUijIaHYeH2b6QaPXkn5408mQU4LsrY4KDUVXU+jmFwIFfa Ug== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 32bs1mk8c3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Jul 2020 13:27:16 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06MDPlCB151849; Wed, 22 Jul 2020 13:27:16 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 32epb584vv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Jul 2020 13:27:16 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 06MDRBYJ029023; Wed, 22 Jul 2020 13:27:11 GMT Received: from ca-mkp.ca.oracle.com (/10.159.214.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Jul 2020 13:27:11 +0000 To: Christoph Hellwig Cc: Daejun Park , "avri.altman@wdc.com" , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "asutoshd@codeaurora.org" , "beanhuo@micron.com" , "stanley.chu@mediatek.com" , "cang@codeaurora.org" , "bvanassche@acm.org" , "tomas.winkler@intel.com" , ALIM AKHTAR , "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Sang-yoon Oh , Sung-Jun Park , yongmyung lee , Jinyoung CHOI , Adel Choi , BoRam Shin Subject: Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support From: "Martin K. Petersen" Organization: Oracle Corporation Message-ID: References: <963815509.21594636682161.JavaMail.epsvc@epcpadp2> <20200722063937.GA21117@infradead.org> Date: Wed, 22 Jul 2020 09:27:07 -0400 In-Reply-To: <20200722063937.GA21117@infradead.org> (Christoph Hellwig's message of "Wed, 22 Jul 2020 07:39:37 +0100") MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9689 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 suspectscore=1 spamscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007220097 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9689 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 bulkscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015 spamscore=0 mlxscore=0 impostorscore=0 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007220097 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph, > As this monster seesm to come back again and again let me re-iterate > my statement: > > I do not think Linux should support a broken standards extensions that > creates a huge share state between the Linux initator and the target > device like this with all its associated problems. I spent a couple of hours looking at this series again last night. And while the code has improved, I do remain concerned about the general concept. I understand how caching the FTL in host memory can improve performance from a theoretical perspective. However, I am not sure how much a difference this is going to make outside of synthetic benchmarks. What are the workloads that keep reading the same blocks from media? Or does the performance improvement exclusively come from the second order pre-fetching effect for larger I/Os? If so, why is the device's internal L2P SRAM cache ineffective at handling that case? -- Martin K. Petersen Oracle Linux Engineering