lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151022084733.GA24379@mtj.duckdns.org>
Date:	Thu, 22 Oct 2015 17:47:33 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Zhangqing Luo <zhangqing.luo@...cle.com>
Cc:	axboe@...nel.dk, Guru Anbalagane <guru.anbalagane@...cle.com>,
	Feng Jin <joe.jin@...cle.com>, linux-kernel@...r.kernel.org
Subject: Re: blk-mq: takes hours for scsi scanning finish when thousands of
 LUNs

Hello,

On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote:
....
> So every time blk_mq_freeze_queue_start, it runs in this way
> 
> blk_mq_freeze_queue_start
> ->percpu_ref_kill->percpu_ref_kill_and_confirm
> ->__percpu_ref_switch_to_atomic
> ->call_rcu_sched(&ref->rcu,percpu_ref_switch_to_atomic_rcu)
> 
> and blk_mq_freeze_queue_wait blocks on queue->mq_usage_counter
> as it is not zero, and wake up by percpu_ref_switch_to_atomic_rcu
> after a grace period
> 
> 
> My question here is why should we change ref to PERCPU at blk_mq_finish_init?
> because of this changing, delay appears.

Because percpu operation is way cheaper than atomic ones and we want
to optimize hot paths (request issue and completion) over cold paths
(init and config changes).  That's the whole point of percpu
refcnting.

The reason why percpu ref starts in atomic mode is to avoid expensive
percpu freezing if the queue is created and abandoned in quick
succession as SCSI does during LUN scanning.  If percpu freezing is
happening during that, the right solution is moving finish_init to
late enough point so that percpu switching happens only after it's
known that the queue won't be abandoned.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ