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]
Date:	Thu, 11 Dec 2008 19:41:02 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Vladislav Bolkhovitin <vst@...b.net>
Cc:	linux-scsi@...r.kernel.org,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Mike Christie <michaelc@...wisc.edu>,
	Jeff Garzik <jeff@...zik.org>,
	Boaz Harrosh <bharrosh@...asas.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, scst-devel@...ts.sourceforge.net,
	Bart Van Assche <bart.vanassche@...il.com>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Subject: Re: [PATCH][RFC 13/23]: Export of alloc_io_context() function

On Thu, Dec 11 2008, Vladislav Bolkhovitin wrote:
> Jens Axboe wrote:
> >On Wed, Dec 10 2008, Vladislav Bolkhovitin wrote:
> >>This patch exports alloc_io_context() function. For performance reasons 
> >>SCST queues commands using a pool of IO threads. It is considerably 
> >>better for performance (>30% increase on sequential reads) if threads in 
> >>  a pool have the same IO context. Since SCST can be built as a module, 
> >>it needs alloc_io_context() function exported.
> >>
> >>Signed-off-by: Vladislav Bolkhovitin <vst@...b.net>
> >>---
> >>  block/blk-ioc.c |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >>diff -upkr linux-2.6.27.2/block/blk-ioc.c linux-2.6.27.2/block/blk-ioc.c
> >>--- linux-2.6.27.2/block/blk-ioc.c	2008-10-10 02:13:53.000000000 +0400
> >>+++ linux-2.6.27.2/block/blk-ioc.c	2008-11-25 21:27:01.000000000 +0300
> >>@@ -105,6 +105,7 @@ struct io_context *alloc_io_context(gfp_
> >> 
> >> 	return ret;
> >> }
> >>+EXPORT_SYMBOL(alloc_io_context);
> >
> >Why is this needed, can't you just use CLONE_IO?
> 
> There are two reasons for that:
> 
> 1. kthread interface doesn't support passing CLONE_IO flag.

Then you fix that instead of working around it! :-)

> 2. Each (virtual) device has own pool of threads, which serves it. 
> Threads in each such pools should have a common IO context, but 
> different pools should have different IO contexts. So, it would be 
> necessary to implement two levels start of IO threads in each pool. At 
> first, one thread would be started. Then it would call get_io_context() 
> to gain io_context. Then it would create the remaining threads with 
> CLONE_IO flag. Definitely, it's a lot more complicated than a simple 
> call of alloc_io_context() and assignment of the returned context to 
> each just created thread in a loop before they were ran.

Just start the first thread without CLONE_IO, and subsequent threads
fork off that with CLONE_IO set? I think we need to make sure that we
allocate an IO context for the 'parent' if it doesn't have one already
and CLONE_IO is set, but that is something that can easily be rectified.
It may seem more complex, but if you use this approach you are pretty
much free to worry about any changes in the future there.

-- 
Jens Axboe

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