From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941254AbcLVP2f (ORCPT ); Thu, 22 Dec 2016 10:28:35 -0500 Received: from mail-wj0-f173.google.com ([209.85.210.173]:34793 "EHLO mail-wj0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757887AbcLVP2d (ORCPT ); Thu, 22 Dec 2016 10:28:33 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCHSET v4] blk-mq-scheduling framework From: Paolo Valente In-Reply-To: Date: Thu, 22 Dec 2016 16:28:27 +0100 Cc: Jens Axboe , linux-block@vger.kernel.org, Linux-Kernal , Omar Sandoval , Linus Walleij , Ulf Hansson , Mark Brown Message-Id: <37570439-97C8-4009-B143-C5E78789A137@linaro.org> References: <1481933536-12844-1-git-send-email-axboe@fb.com> <7A8A5078-E9B8-4EBF-BAB1-9E8EEBF3A043@linaro.org> To: Jens Axboe X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uBMFSe51015727 > Il giorno 19 dic 2016, alle ore 22:05, Jens Axboe ha scritto: > > On 12/19/2016 11:21 AM, Paolo Valente wrote: >> >>> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe ha scritto: >>> >>> On 12/19/2016 04:32 AM, Paolo Valente wrote: >>>> >>>>> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe ha scritto: >>>>> >>>>> This is version 4 of this patchset, version 3 was posted here: >>>>> >>>>> https://marc.info/?l=linux-block&m=148178513407631&w=2 >>>>> >>>>> From the discussion last time, I looked into the feasibility of having >>>>> two sets of tags for the same request pool, to avoid having to copy >>>>> some of the request fields at dispatch and completion time. To do that, >>>>> we'd have to replace the driver tag map(s) with our own, and augment >>>>> that with tag map(s) on the side representing the device queue depth. >>>>> Queuing IO with the scheduler would allocate from the new map, and >>>>> dispatching would acquire the "real" tag. We would need to change >>>>> drivers to do this, or add an extra indirection table to map a real >>>>> tag to the scheduler tag. We would also need a 1:1 mapping between >>>>> scheduler and hardware tag pools, or additional info to track it. >>>>> Unless someone can convince me otherwise, I think the current approach >>>>> is cleaner. >>>>> >>>>> I wasn't going to post v4 so soon, but I discovered a bug that led >>>>> to drastically decreased merging. Especially on rotating storage, >>>>> this release should be fast, and on par with the merging that we >>>>> get through the legacy schedulers. >>>>> >>>> >>>> I'm to modifying bfq. You mentioned other missing pieces to come. Do >>>> you already have an idea of what they are, so that I am somehow >>>> prepared to what won't work even if my changes are right? >>> >>> I'm mostly talking about elevator ops hooks that aren't there in the new >>> framework, but exist in the old one. There should be no hidden >>> surprises, if that's what you are worried about. >>> >>> On the ops side, the only ones I can think of are the activate and >>> deactivate, and those can be done in the dispatch_request hook for >>> activate, and put/requeue for deactivate. >>> >> >> You mean that there is no conceptual problem in moving the code of the >> activate interface function into the dispatch function, and the code >> of the deactivate into the put_request? (for a requeue it is a little >> less clear to me, so one step at a time) Or am I missing >> something more complex? > > Yes, what I mean is that there isn't a 1:1 mapping between the old ops > and the new ops. So you'll have to consider the cases. > > Problem: whereas it seems easy and safe to do somewhere else the simple increment that was done in activate_request, I wonder if it may happen that a request is deactivate before being completed. In it may happen, then, without a deactivate_request hook, the increments would remain unbalanced. Or are request completions always guaranteed till no hw/sw components breaks? Thanks, Paolo > -- > Jens Axboe > > -- > To unsubscribe from this list: send the line "unsubscribe linux-block" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html