From patchwork Fri May 15 07:41:47 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Borntraeger X-Patchwork-Id: 6412021 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 801EE9F318 for ; Fri, 15 May 2015 07:41:57 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B2ADF202EC for ; Fri, 15 May 2015 07:41:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ADFED2025A for ; Fri, 15 May 2015 07:41:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932112AbbEOHly (ORCPT ); Fri, 15 May 2015 03:41:54 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:46260 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754264AbbEOHlx (ORCPT ); Fri, 15 May 2015 03:41:53 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 15 May 2015 08:41:52 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 15 May 2015 08:41:49 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id D75D81B08069 for ; Fri, 15 May 2015 08:42:34 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t4F7fmeD8454458 for ; Fri, 15 May 2015 07:41:48 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t4F2ZgGJ024419 for ; Thu, 14 May 2015 22:35:43 -0400 Received: from oc1450873852.ibm.com (dyn-9-152-224-132.boeblingen.de.ibm.com [9.152.224.132]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t4F2Zg3I024401; Thu, 14 May 2015 22:35:42 -0400 Message-ID: <5555A33B.20006@de.ibm.com> Date: Fri, 15 May 2015 09:41:47 +0200 From: Christian Borntraeger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gu Zheng , Benjamin LaHaise CC: linux-aio@kvack.org, linux-fsdevel@vger.kernel.org Subject: Revert "aio: block exit_aio() until all context requests are completed" References: <1431675417-30464-1-git-send-email-borntraeger@de.ibm.com> In-Reply-To: <1431675417-30464-1-git-send-email-borntraeger@de.ibm.com> X-Forwarded-Message-Id: <1431675417-30464-1-git-send-email-borntraeger@de.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15051507-0013-0000-0000-000003FC8E4D Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I see a significant latency (can be minutes with 2000 disks and HZ=100) when exiting a QEMU process that has lots of disk devices via aio. The process sits idle doing nothing as zombie in exit_aio waiting for the completion. Turns out that commit 6098b45b32 ("aio: block exit_aio() until all context requests are completed") caused the delay. Patch description was: It seems that exit_aio() also needs to wait for all iocbs to complete (like io_destroy), but we missed the wait step in current implemention, so fix it in the same way as we did in io_destroy. Now: io_destroy requires to block until everything is cleaned up from its interface description in the manpage: DESCRIPTION The io_destroy() system call will attempt to cancel all outstanding asynchronous I/O operations against ctx_id, will block on the completion of all operations that could not be canceled, and will destroy the ctx_id. Does process exit require the same full blocking? We might be able to cleanup the process and let the aio data structures be freed lazily. Opinions or better ideas? Christian --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/aio.c b/fs/aio.c index a793f70..1e6bcdb 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -820,8 +820,6 @@ void exit_aio(struct mm_struct *mm) for (i = 0; i < table->nr; ++i) { struct kioctx *ctx = table->table[i]; - struct completion requests_done = - COMPLETION_INITIALIZER_ONSTACK(requests_done); if (!ctx) continue; @@ -833,10 +831,7 @@ void exit_aio(struct mm_struct *mm) * that it needs to unmap the area, just set it to 0. */ ctx->mmap_size = 0; - kill_ioctx(mm, ctx, &requests_done); - - /* Wait until all IO for the context are done. */ - wait_for_completion(&requests_done); + kill_ioctx(mm, ctx, NULL); } RCU_INIT_POINTER(mm->ioctx_table, NULL);