Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934219AbeAIQTU (ORCPT + 1 other); Tue, 9 Jan 2018 11:19:20 -0500 Received: from mail-qt0-f170.google.com ([209.85.216.170]:46977 "EHLO mail-qt0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933629AbeAIQTS (ORCPT ); Tue, 9 Jan 2018 11:19:18 -0500 X-Google-Smtp-Source: ACJfBosfBCKbEgKxXFNhJ+0fLOttH7Qam+gR7uW1PqP7eE5G23YXrRVKa1/khaVaCvJO3yvxeRp6Ug== Date: Tue, 9 Jan 2018 08:19:14 -0800 From: "tj@kernel.org" To: Bart Van Assche Cc: "jbacik@fb.com" , "jack@suse.cz" , "clm@fb.com" , "axboe@kernel.dk" , "kernel-team@fb.com" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "linux-btrfs@vger.kernel.org" , "linux-block@vger.kernel.org" , "jianchao.w.wang@oracle.com" Subject: Re: [PATCH 2/8] blk-mq: protect completion path with RCU Message-ID: <20180109161914.GM3668920@devbig577.frc2.facebook.com> References: <20180108191542.379478-1-tj@kernel.org> <20180108191542.379478-3-tj@kernel.org> <1515514359.2721.9.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515514359.2721.9.camel@wdc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hello, Bart. On Tue, Jan 09, 2018 at 04:12:40PM +0000, Bart Van Assche wrote: > I'm concerned about the additional CPU cycles needed for the new blk_mq_map_queue() > call, although I know this call is cheap. Would the timeout code really get that So, if that is really a concern, let's cache that mapping instead of changing synchronization rules for that. > much more complicated if the hctx_lock() and hctx_unlock() calls would be changed > into rcu_read_lock() and rcu_read_unlock() calls? Would it be sufficient if > "if (has_rcu) synchronize_rcu();" would be changed into "synchronize_rcu();" in > blk_mq_timeout_work()? Code-wise, it won't be too much extra code but I think diverging the sync methods between issue and completion paths is more fragile and likely to invite confusions and mistakes in the future. We have the normal path (issue&completion) synchronizing against the exception path (timeout). I think it's best to keep the sync constructs aligned with that conceptual picture. Thanks. -- tejun