Re: [patch] aio: streamline read events after woken up
buffer index there. By then, most of you would probably veto the patch anyway ;-) haha, touche :) I still think it'd be the right thing, though. We can let the patch speak for itself :). - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] aio: streamline read events after woken up
Zach Brown wrote on Tuesday, January 02, 2007 5:06 PM > To: Chen, Kenneth W > > Given the previous patch "aio: add per task aio wait event condition" > > that we properly wake up event waiting process knowing that we have > > enough events to reap, it's just plain waste of time to insert itself > > into a wait queue, and then immediately remove itself from the wait > > queue for *every* event reap iteration. > > Hmm, I dunno. It seems like we're still left with a pretty silly loop. > > Would it be reasonable to have a loop that copied multiple events at > a time? We could use some __copy_to_user_inatomic(), it didn't exist > when this stuff was first written. It sounds reasonable, but I think it will be complicated because of kmap_atomic on the ring buffer, along with tail wraps around ring buffer index there. By then, most of you would probably veto the patch anyway ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: streamline read events after woken up
Given the previous patch "aio: add per task aio wait event condition" that we properly wake up event waiting process knowing that we have enough events to reap, it's just plain waste of time to insert itself into a wait queue, and then immediately remove itself from the wait queue for *every* event reap iteration. Hmm, I dunno. It seems like we're still left with a pretty silly loop. Would it be reasonable to have a loop that copied multiple events at a time? We could use some __copy_to_user_inatomic(), it didn't exist when this stuff was first written. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: streamline read events after woken up
Given the previous patch aio: add per task aio wait event condition that we properly wake up event waiting process knowing that we have enough events to reap, it's just plain waste of time to insert itself into a wait queue, and then immediately remove itself from the wait queue for *every* event reap iteration. Hmm, I dunno. It seems like we're still left with a pretty silly loop. Would it be reasonable to have a loop that copied multiple events at a time? We could use some __copy_to_user_inatomic(), it didn't exist when this stuff was first written. - z - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] aio: streamline read events after woken up
Zach Brown wrote on Tuesday, January 02, 2007 5:06 PM To: Chen, Kenneth W Given the previous patch aio: add per task aio wait event condition that we properly wake up event waiting process knowing that we have enough events to reap, it's just plain waste of time to insert itself into a wait queue, and then immediately remove itself from the wait queue for *every* event reap iteration. Hmm, I dunno. It seems like we're still left with a pretty silly loop. Would it be reasonable to have a loop that copied multiple events at a time? We could use some __copy_to_user_inatomic(), it didn't exist when this stuff was first written. It sounds reasonable, but I think it will be complicated because of kmap_atomic on the ring buffer, along with tail wraps around ring buffer index there. By then, most of you would probably veto the patch anyway ;-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: streamline read events after woken up
buffer index there. By then, most of you would probably veto the patch anyway ;-) haha, touche :) I still think it'd be the right thing, though. We can let the patch speak for itself :). - z - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
