linux-kernel - Re: [PATCH 17/32] scsi/ibmvstgt: use system

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jan 2011 17:24:14 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Bart Van Assche <bvanassche@....org>
Cc:	linux-kernel@...r.kernel.org,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
	linux-scsi@...r.kernel.org, Brian King <brking@...ux.vnet.ibm.com>,
	Robert Jennings <rcj@...ux.vnet.ibm.com>
Subject: Re: [PATCH 17/32] scsi/ibmvstgt: use system_wq instead of vtgtd
 workqueue

Hello,

On Mon, Jan 24, 2011 at 05:09:18PM +0100, Bart Van Assche wrote:
> Insertion of  flush_work_sync() fixes a race - that's a good catch.
> flush_work_sync() should be invoked a little earlier though because
> the scheduled work may access the queue destroyed by the
> crq_queue_destroy(target) call. And the CRQ interrupt should be
> disabled from before flush_work_sync() is invoked until after the CRQ
> has been destroyed.

Heh, I'm a bit out of my depth here.  If you know what's necessary,
please go ahead and make the change.

> Regarding the queue removal: I might have missed something, but why
> would you like to remove the vtgtd work queue ? Since the ibmvstgt
> driver is a storage target driver, processing latency matters. I'm
> afraid that switching from a dedicated queue to the global work queue
> will increase processing latency.

Having a dedicated workqueue no longer makes any difference regarding
processing latency.  Each workqueue is mere frontend to the shared
worker pool anyway.  Dedicated workqueues are now meaningful only as
forward progress guarantee, attribute and/or flush domain - IOW, when
the workqueue needs to be used during memory reclaim, the work items
need to have specific attributes or certain group of work items need
to be flushed together.  Apart from that, there's virtually no
difference between using the system_wq and a dedicated one.  As using
the system one is usually simpler, it's natural to do that.

Thank you.

-- 
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/