From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zheng Liu Subject: [LST/MM TOPIC] really non-blocking in aio stack Date: Mon, 13 Feb 2012 23:35:09 +0800 Message-ID: <20120213153509.GA7830@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: lsf-pc@lists.linux-foundation.org Return-path: Received: from mail-pw0-f46.google.com ([209.85.160.46]:55482 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753487Ab2BMPaf (ORCPT ); Mon, 13 Feb 2012 10:30:35 -0500 Received: by pbcun15 with SMTP id un15so4635897pbc.19 for ; Mon, 13 Feb 2012 07:30:35 -0800 (PST) Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi all, Currently native aio has been used in many critical applications like innodb of MySQL and Nginx for a web server. But it is really not as asynchronous as the user expects. __getblk() can be blocked by the metadata allocation, and get_reuqest() can sleep because of the queue congestion. So the user is really annoyed by the delay. So we want to improve it somehow to make it at least really non-blocking. Although we have define EIOCBRETRY, it seems to me that it is not used as perfect as it can. We can return a EIOCBRETRY when the underlying work will be blocked, and the generic aio can be tuned to either do it asynchronously or notify the user about the status and let the user have been no finalization yet. So maybe we can take this chance to discuss it since now at least it really hurts some very important applications in the world. I am sorry that I forgot to send a topic to mailing list before the deadline. Hope it isn't too late. Regards, Zheng