From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261617AbVFTVtK (ORCPT ); Mon, 20 Jun 2005 17:49:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261632AbVFTVsV (ORCPT ); Mon, 20 Jun 2005 17:48:21 -0400 Received: from kanga.kvack.org ([66.96.29.28]:41158 "EHLO kanga.kvack.org") by vger.kernel.org with ESMTP id S261642AbVFTVoh (ORCPT ); Mon, 20 Jun 2005 17:44:37 -0400 Date: Mon, 20 Jun 2005 17:46:14 -0400 From: Benjamin LaHaise To: linux-aio@kvack.org Cc: linux-kernel@vger.kernel.org Subject: Re: aio_down() patch series -- cancellation support added Message-ID: <20050620214614.GC6628@kvack.org> References: <20050620213835.GA6628@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050620213835.GA6628@kvack.org> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Add linux-kernel to the Cc list... On Mon, Jun 20, 2005 at 05:38:35PM -0400, Benjamin LaHaise wrote: > Hello all, > > The patch series at http://www.kvack.org/~bcrl/patches/aio-2.6.12-A1/ > now adds support for cancellation of an aio_down() operation. The > races should be correctly handled by introducing per-kiocb locking > that serialises ->ki_cancel() and ->ki_retry(). The interesting patch > additions are 40_lock_kiocb 50_aio_down_cancel.diff. Comments? > > -ben > -- > "Time is what keeps everything from happening all at once." -- John Wheeler > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majordomo@kvack.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: aart@kvack.org -- "Time is what keeps everything from happening all at once." -- John Wheeler From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262498AbVFWN1A (ORCPT ); Thu, 23 Jun 2005 09:27:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262216AbVFWNXg (ORCPT ); Thu, 23 Jun 2005 09:23:36 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:18590 "EHLO e3.ny.us.ibm.com") by vger.kernel.org with ESMTP id S262406AbVFWNUK (ORCPT ); Thu, 23 Jun 2005 09:20:10 -0400 Date: Thu, 23 Jun 2005 18:59:26 +0530 From: Suparna Bhattacharya To: Benjamin LaHaise Cc: linux-aio@kvack.org, linux-kernel@vger.kernel.org Subject: Re: aio_down() patch series -- cancellation support added Message-ID: <20050623132926.GA6669@in.ibm.com> Reply-To: suparna@in.ibm.com References: <20050620213835.GA6628@kvack.org> <20050620214614.GC6628@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050620214614.GC6628@kvack.org> User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 20, 2005 at 05:46:14PM -0400, Benjamin LaHaise wrote: > Add linux-kernel to the Cc list... > > On Mon, Jun 20, 2005 at 05:38:35PM -0400, Benjamin LaHaise wrote: > > Hello all, > > > > The patch series at http://www.kvack.org/~bcrl/patches/aio-2.6.12-A1/ > > now adds support for cancellation of an aio_down() operation. The > > races should be correctly handled by introducing per-kiocb locking > > that serialises ->ki_cancel() and ->ki_retry(). The interesting patch > > additions are 40_lock_kiocb 50_aio_down_cancel.diff. Comments? > > > > -ben > > -- One quick question. Since lock_kiocb() may block, does that mean that the aio worker thread could be put to sleep while an iocb cancellation is in progress, even though there may be other iocbs/ioctx's to process ? Looking at the rest a little more closely in terms of how everything will fit together, a few questions come to mind - need to think about it a little more. I guess the main reason you need the aio_down_wait callback is to make sure the semaphore is grabbed right in the context of the wakeup rather than at retry time, is that correct ? Regards Suparna -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Lab, India From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262612AbVFWQkA (ORCPT ); Thu, 23 Jun 2005 12:40:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262613AbVFWQkA (ORCPT ); Thu, 23 Jun 2005 12:40:00 -0400 Received: from kanga.kvack.org ([66.96.29.28]:61338 "EHLO kanga.kvack.org") by vger.kernel.org with ESMTP id S262612AbVFWQj6 (ORCPT ); Thu, 23 Jun 2005 12:39:58 -0400 Date: Thu, 23 Jun 2005 12:41:37 -0400 From: Benjamin LaHaise To: Suparna Bhattacharya Cc: linux-aio@kvack.org, linux-kernel@vger.kernel.org Subject: Re: aio_down() patch series -- cancellation support added Message-ID: <20050623164137.GA5279@kvack.org> References: <20050620213835.GA6628@kvack.org> <20050620214614.GC6628@kvack.org> <20050623132926.GA6669@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050623132926.GA6669@in.ibm.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2005 at 06:59:26PM +0530, Suparna Bhattacharya wrote: > One quick question. > Since lock_kiocb() may block, does that mean that the aio worker thread > could be put to sleep while an iocb cancellation is in progress, even though > there may be other iocbs/ioctx's to process ? It's mostly to deal with the case in the other direction: an iocb that is in the process of being cancelled somehow needs to block any retries from occurring. Likewise, if a retry was in progress, the cancellation needs to be blocked until that retry is complete. It should be sufficiently rare that it's not a problem, but we may have to revisit the issue as more cancel methods get written. > Looking at the rest a little more closely in terms of how everything > will fit together, a few questions come to mind - need to think > about it a little more. I guess the main reason you need the aio_down_wait > callback is to make sure the semaphore is grabbed right in the context > of the wakeup rather than at retry time, is that correct ? Yes, that way the retry method is only called if it will make progress, and we will not have a thundering herd problem. I'm debugging the changes needed to implement async pipes using aio_down(), and the patch so far looks pretty straightforward. -ben -- "Time is what keeps everything from happening all at once." -- John Wheeler