From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH v2 11/13] dm-mpath: Micro-optimize the hot path Date: Thu, 27 Apr 2017 16:39:48 -0400 Message-ID: <20170427203948.GA70128@redhat.com> References: <20170427171126.26814-1-bart.vanassche@sandisk.com> <20170427171126.26814-12-bart.vanassche@sandisk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170427171126.26814-12-bart.vanassche@sandisk.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Bart Van Assche Cc: dm-devel@redhat.com List-Id: dm-devel.ids On Thu, Apr 27 2017 at 1:11P -0400, Bart Van Assche wrote: > Instead of checking MPATHF_QUEUE_IF_NO_PATH, > MPATHF_SAVED_QUEUE_IF_NO_PATH and the no_flush flag to decide whether > or not to push back a request if there are no paths available, only > clear MPATHF_QUEUE_IF_NO_PATH in queue_if_no_path() if no_flush has > not been set. The result is that only a single bit has to be tested > in the hot path to decide whether or not a request must be pushed > back and also that m->lock does not have to be taken in the hot path. > > Signed-off-by: Bart Van Assche > Reviewed-by: Hannes Reinecke This patch was very demanding to review.. all that old must_push_back() code was very tedious. Happy to see it go. BUT I'm left nervous that something might regress. Not because of something overlooked (though that could happen).. just that its a particularly delicate portion of the mpath target's suspend/resume handling. Kudos to you for tackling this. Staged in dm-4.12 for 4.12 inclusion (will push it out once I go back over what I've staged)