From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ted Ts'o Subject: Re: [ATTEND] Attendance request Date: Thu, 2 Feb 2012 15:58:43 -0500 Message-ID: <20120202205843.GD1032@thunk.org> References: <4F2ABF08.60502@oracle.com> <20120202202911.GC1032@thunk.org> <4F2AF737.9020106@zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Kleikamp , linux-fsdevel@vger.kernel.org To: Zach Brown Return-path: Received: from li9-11.members.linode.com ([67.18.176.11]:55446 "EHLO test.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754048Ab2BBU6r (ORCPT ); Thu, 2 Feb 2012 15:58:47 -0500 Content-Disposition: inline In-Reply-To: <4F2AF737.9020106@zabbo.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Feb 02, 2012 at 03:51:03PM -0500, Zach Brown wrote: > > Well, for that one blocking case in the submission path. > > I certainly understand the desire to just make things less painful in > this case, but I do wonder if the long-term win is to sink resources > into trying to get threads executings async op so that the code paths > don't have to be butchered into state machines around each potential > blocking op. I only intend to do this for reads and non-allocating writes; in those cases, it's actually pretty easy. And if everything is already in cache, it's a lot easier to make things fast and not require diving into workqueue or some other kernel thread. My concern with just stuffing every single io_submit into a kernel thread is the overhead involved, especially if there is a high rate of AIO submission (think high-speed PCIe-attached flash). Either you will end up blocking waiting for a kernel thread to be available, or you will burn a huge amount of kernel memory for the thread stacks if nothing else. - Ted