Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4239518imm; Wed, 30 May 2018 01:37:16 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI1SK5AeqLB14OEhF0UBSuy8UslTZh42YwCByO4eS6OSzrML8F81M9J7fZY5qnDHZvU1xyv X-Received: by 2002:a62:98c9:: with SMTP id d70-v6mr1757560pfk.195.1527669436258; Wed, 30 May 2018 01:37:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527669436; cv=none; d=google.com; s=arc-20160816; b=UhuuCrrTxwKUd4sTQNtIFY3NEYHAAIkgIf8tWz/QWbgBZ7ZYn0zFtkhvk4n8VChaF5 +WE2oQ6O4vc3ARYKeIRdxwtzTylxZ2tdG/OeWhHtF37kBnyU09n7sb+ZUZFCD35A7u3F k1OLLFGjy30XguZcRnwOynF99uJO+k+PoHniZWu5oI0/QH2B1Vw7540a5en7dFZb7Hg0 2yPHRiO8xeoON4Z60i2QSC3c4AO/6IzIIXlulwBptXnS9mG9PwpJmJSx/AbQDtL1F+nk PPUGUWT/lwZbKnA9xl99gBWBaCfNX7BgxKl7WAR0F3KnPsDSwk3SKsZ7oCa9OsFTxpoJ S3xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=0PWbr9OxnTH7cET4rvz2lo0/+VwVspI9OfMNcmhjhjc=; b=enpQ/xCI23eqqVH6PVGghyI83ciluu3Xncuxc6Hs9FFC1cNWA9tnuXNEvkUyqGe95F p5tOWj39faGwlgHmDVQRMM2onjJpW18ZRqMWLxNVUEbzRcvh2Qf58wbIBJ83BEPh0D1E z87vLhTIi2WGzcmPKHAZRz7tk29qkzIj5NFF76PPUvXed0yYhFcqNBEa6Kd6YOQ68I2R b+Uevrrq+Wjqm2qIsBmvxLUCJ7JIgBrh9R9yBYY+z8hbJ6KPs9dRHfy991rob7LgC5Eg 8hLb0DjZgixPVxllgCg6Q2uer4lw8tOHPBfiATcdVu7QReH3pUeVqnYhWkhioVheRTdf a30g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=ciKRhFSw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id e13-v6si24396687pgt.332.2018.05.30.01.37.02; Wed, 30 May 2018 01:37:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=ciKRhFSw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S937284AbeE3Ig3 (ORCPT + 99 others); Wed, 30 May 2018 04:36:29 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:37660 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935953AbeE3IgZ (ORCPT ); Wed, 30 May 2018 04:36:25 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4U8aAsu105158; Wed, 30 May 2018 08:36:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=0PWbr9OxnTH7cET4rvz2lo0/+VwVspI9OfMNcmhjhjc=; b=ciKRhFSwty8J701eiIJKr8TLgC09WjfXtQtDrR57kdrC5dsOSkcZ5q30q8XSITyvtbpT xkwMANbwob0SkwDuMY/pVMvRczy9nCHMl3R8jNuTp9nQkE/RBBZLt4QOpluGWudHzFQE 4USAADOSdzioZ2ccNX85D3aDvmkpp4poNyY77zwKWTLLWYw2vsmGxn6vKi4fOKIGiKUt y/Jv/C7DUux07elKqDga9OG81qoQBae1YkFUAFEzC4Gsyz6aEnAr1q8G+3A1GBve/V2A Ll2k12J4obMeuZnVfKhBj8EjeW1L3J+8DFK5DrsplcOC7Ykmtx54FwZOaaMjttzhbu0J jg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2j9ev89ba8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 08:36:19 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4U8aJSn021433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 08:36:19 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4U8aJ0p024481; Wed, 30 May 2018 08:36:19 GMT Received: from [10.182.70.180] (/10.182.70.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2018 01:36:18 -0700 Subject: Re: [PATCH] block: kyber: make kyber more friendly with merging To: Ming Lei Cc: Omar Sandoval , Jens Axboe , linux-block , Linux Kernel Mailing List References: <1527000509-2619-1-git-send-email-jianchao.w.wang@oracle.com> <20180522200214.GF9536@vader> From: "jianchao.wang" Message-ID: Date: Wed, 30 May 2018 16:36:32 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8908 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=646 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805300101 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi ming Thanks for your kindly response. On 05/30/2018 04:22 PM, Ming Lei wrote: >>> you could keep the software queues as-is but add our own version of >>> flush_busy_ctxs() that only removes requests of the domain that we want. >>> If one domain gets backed up, that might get messy with long iterations, >>> though. >> Yes, I also considered this approach :) >> But the long iterations on every ctx->rq_list looks really inefficient. > Right, this list can be quite long if dispatch token is used up. > > You might try to introduce per-domain list into ctx directly, then 'none' > may benefit from this change too since bio merge should be done > on the per-domain list actually. Yes, it maybe good for merging of 'none', because the rq_list is split into 3 lists, and not need to iterate the whole rq_list any more. But what's about the dispatch when there is no io scheduler. We will dispatch request from ctx one by one at the moment. If we have per-domain list in ctx, we have to introduce some policies to determine which domain to dispatch, and these policies should be in io scheduler actually. Thanks Jianchao