linux-kernel - Re: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio

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:	Wed, 21 Aug 2013 16:24:48 -0400
From:	Benjamin LaHaise <bcrl@...ck.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Kleikamp <dave.kleikamp@...cle.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	"Maxim V. Patlasov" <mpatlasov@...allels.com>,
	Zach Brown <zab@...bo.net>, linux-aio@...ck.org
Subject: Re: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio_vec

On Wed, Aug 21, 2013 at 12:30:32PM -0700, Andrew Morton wrote:
> On Wed, 21 Aug 2013 09:02:31 -0400 Benjamin LaHaise <bcrl@...ck.org> wrote:
> 
> > One of the major problems your changeset continues to carry is that your 
> > new read_iter/write_iter operations permit blocking (implicitely), which 
> > really isn't what we want for aio.  If you're going to introduce a new api, 
> > it should be made non-blocking, and enforce that non-blocking requirement 
> 
> It's been so incredibly long and I've forgotten everything AIO :(
> 
> In this context, "non-blocking" means no synchronous IO, yes?  Even for
> indirect blocks, etc.  What about accidental D-state blockage in page
> reclaim, or against random sleeping locks?

Those are all no-nos.  Blocking for memory allocation for short durations 
is okay, but not for wandering off into scan-the-world type ordeals (that 
is, it should be avoided).

> Also, why does this requirement exist?  "99% async" is not good enough?
> How come?

99% async is okay for the database folks, but not for all users.  Think 
unified event loops.  For example, the application I'm currently working 
on is using AIO to isolate disk access from blocking the main thread.  If 
things go off and block on random locks or on disk I/O, bad things happen, 
like watchdogs triggering.  One of the real world requirements we have is 
that the application has to keep running even if the disks we're running 
on go bad.  With SANs and multipath involved, sometimes I/O can take tens 
of seconds to complete.  You also don't want to block operations that can 
proceed by those that are presently blocked, as that reduces the available 
parallelism to devices and increases overall latency.

I'll admit there's a lot of work to be done in this area, hence why I've 
done some work on thread based AIO recently, but threads aren't great for 
all use-cases.  Ultimately something like Zach's schedulable stacks are 
needed to get the overhead down to something reasonable.

Still, we shouldn't keep on propagating broken APIs that don't reflect 
actual requirements.

		-ben
-- 
"Thought is the essence of where you are now."
--
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/