Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp790065imm; Tue, 15 May 2018 09:12:15 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr/4kPAsu1I//qQvLP6c7zeMeKqavWc+okGY+1lTJM3+CPS+Aa2rhqMQNK9/Fa3DcHQ7fQv X-Received: by 2002:a17:902:7446:: with SMTP id e6-v6mr14891665plt.369.1526400735247; Tue, 15 May 2018 09:12:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526400735; cv=none; d=google.com; s=arc-20160816; b=Bgr22vGgwh6xzL1jec69ln88plk08zVRzkkEPC2Rmx/iSGTEQ9KHJUIKL1zwmkS7mO 5PIArSA363m012lEC19HnL4SXw63z+zZXPK1jR8JZbcJA+LPaXhadCRs+yrHw1T5HyeR ogPPUmXf/M2j6Ul/yJWWhafBFFgvQ052CN7sSSV9/FieC/dFU7URDWCO1A1G98p26wIE KyBBY9dw0Gj18bhJWHPXV6IyM8FzO2RHccGLr6AHoRVDvX1F3PnNe4KJVEbfnqiCZKUq YCmz+i2gXz5qePOShbuEoKBR+9/e3FjSkZ89tU4tytMdSDXVb0ySq2cfo3nlAa9vCFmR p5Xw== 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=Sj1bePgrLJGjg0HgnTm1ibNqzMpZ8qdJAB0n87QmS4E=; b=IW4bRbi3nO2YzWK1gkeIkLvtZzbXvPLuAdKF8CLj4x0/XzOw0I12B24RxBrwiBvGIN q06/SeiFUrBMczHh8wzKEtKc4FBcZYKbG7G5F4Ma5K2+FisJLcLKF4MBzIqvxh+dVgKq J6cmECogd8DFUSJInCObQxkqlnCOyw+q7irfwps1jDOE9jRUt4RbM1HR939YjIpvbUI0 M3FD/kUj3rNv0v9JF/j08fCTw/BQ9x9DJbmLVXK0mi0wQ72nWBkZG5ytwEgdteW7rsSt X9wo4q4scmX1NGv1dhwKzSysLf5Ho576h9j+NP6lWwmA8PJQ49QR6o5ZdIlP693f/8dM lvCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=oWPpZKTT; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si311397plk.521.2018.05.15.09.12.00; Tue, 15 May 2018 09:12:15 -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=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=oWPpZKTT; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754010AbeEOQLW (ORCPT + 99 others); Tue, 15 May 2018 12:11:22 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:53675 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753435AbeEOQLT (ORCPT ); Tue, 15 May 2018 12:11:19 -0400 Received: by mail-it0-f65.google.com with SMTP id n64-v6so2850540itb.3 for ; Tue, 15 May 2018 09:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Sj1bePgrLJGjg0HgnTm1ibNqzMpZ8qdJAB0n87QmS4E=; b=oWPpZKTTZa96l83QoRiKtgOMQnEVxFw6Sh6bzotnreW4nVlenkylxB/nCXT145HG5L JsyvD10KU70WiG9Lkg5AA25IcQ0ApzoDY54wayv2ta1dJ/Lejd7Ucypzz2rhbc7ekAO3 JOBY1dZmvMhmh3BvJIwB55uFaEqB6A0PaAhisBccHI3s3fydJ8F8zzvKaBKmE2mHZql6 P19ITLQp+q3OMK4QSbF9rSD5dTSOfqUKOoKDxy1QjA9M2kmBn7zYy7vJLIxOxSZh6mYP CRlWcMYN6SHXU3PCAc2uZyEB1RKd4ZneUYkyzVpcIzbBqSb8BJZOOo/NomGWnEXqdH6Z N4lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Sj1bePgrLJGjg0HgnTm1ibNqzMpZ8qdJAB0n87QmS4E=; b=gFqND6m68BBVu2MATEC4qPreQ/Er+77KYUFnG+wUy81GWtHFPSiBhHgsk0ROlJVFwh ixayMrbTJAChlqLAQWmryfpbkgefspgfirnc4e96N83SCx8+IXjlktEHL+spjDmAnuTE xpcVR0dW0Y4eGzx0xvNR9pkEayuWEbiqbZb8ENzFWPi2t2MqfT+BPmu5XSe+3XjdslKY I5E5QuPSODRnm8pgKlBiSr2kAmwFy9ocDaMsOG1Xp8eebuLcyLLj8QjNQtc0ww8BBwe1 BP0gTAj9+RB6yoaLVcWAGprmK76ouzGvjkMSDdqhVeorWcty8UvOo1uiZGYsCdhHQTAa 5UPg== X-Gm-Message-State: ALKqPwdBG8zFLsbwo2jQprDiVE1C83H3BrKGBs4ccruAvbBns2rLWSWJ lzD83+AQ1zZwaj1Ejlr0n5nPLQ== X-Received: by 2002:a6b:9dc1:: with SMTP id g184-v6mr15374609ioe.41.1526400679147; Tue, 15 May 2018 09:11:19 -0700 (PDT) Received: from [192.168.1.167] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id s10-v6sm169655ioc.84.2018.05.15.09.11.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 09:11:17 -0700 (PDT) Subject: Re: [PATCH 1/2] Convert target drivers to use sbitmap To: Matthew Wilcox , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-usb@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, Juergen Gross , qla2xxx-upstream@qlogic.com, Kent Overstreet Cc: Matthew Wilcox References: <20180515160043.27044-1-willy@infradead.org> <20180515160043.27044-2-willy@infradead.org> From: Jens Axboe Message-ID: <3a56027b-47bc-dcb8-a465-3670031572f1@kernel.dk> Date: Tue, 15 May 2018 10:11:15 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180515160043.27044-2-willy@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/15/18 10:00 AM, Matthew Wilcox wrote: > From: Matthew Wilcox > > The sbitmap and the percpu_ida perform essentially the same task, > allocating tags for commands. Since the sbitmap is more used than > the percpu_ida, convert the percpu_ida users to the sbitmap API. It should also be the same performance as percpu_ida in light use, and performs much better at > 50% utilization of the tag space. I think that's better justification than "more used than". > diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c > index 4435bf374d2d..28bcffae609f 100644 > --- a/drivers/target/iscsi/iscsi_target_util.c > +++ b/drivers/target/iscsi/iscsi_target_util.c > @@ -17,7 +17,7 @@ > ******************************************************************************/ > > #include > -#include > +#include > #include /* ipv6_addr_equal() */ > #include > #include > @@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd) > spin_unlock_bh(&cmd->r2t_lock); > } > > +int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup) > +{ > + int tag = -1; > + DEFINE_WAIT(wait); > + struct sbq_wait_state *ws; > + > + if (state == TASK_RUNNING) > + return tag; > + > + ws = &se_sess->sess_tag_pool.ws[0]; > + for (;;) { > + prepare_to_wait_exclusive(&ws->wait, &wait, state); > + if (signal_pending_state(state, current)) > + break; > + schedule(); > + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup); > + } > + > + finish_wait(&ws->wait, &wait); > + return tag; > +} Seems like that should be: ws = &se_sess->sess_tag_pool.ws[0]; for (;;) { prepare_to_wait_exclusive(&ws->wait, &wait, state); if (signal_pending_state(state, current)) break; tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup); if (tag != -1) break; schedule(); } finish_wait(&ws->wait, &wait); return tag; > /* > * May be called from software interrupt (timer) context for allocating > * iSCSI NopINs. > @@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn *conn, int state) > { > struct iscsi_cmd *cmd; > struct se_session *se_sess = conn->sess->se_sess; > - int size, tag; > + int size, tag, cpu; > > - tag = percpu_ida_alloc(&se_sess->sess_tag_pool, state); > + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, &cpu); > + if (tag < 0) > + tag = iscsit_wait_for_tag(se_sess, state, &cpu); > if (tag < 0) > return NULL; Might make sense to just roll the whole thing into iscsi_get_tag(), that would be cleaner. sbitmap should provide a helper for that, but we can do that cleanup later. That would encapsulate things like the per-cpu caching hint too, for instance. Rest looks fine to me. -- Jens Axboe