From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964893AbXDAUU1 (ORCPT ); Sun, 1 Apr 2007 16:20:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964896AbXDAUU1 (ORCPT ); Sun, 1 Apr 2007 16:20:27 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:48924 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964893AbXDAUU0 (ORCPT ); Sun, 1 Apr 2007 16:20:26 -0400 X-AuthUser: davidel@xmailserver.org Date: Sun, 1 Apr 2007 13:20:23 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Avi Kivity cc: Linux Kernel Mailing List , Andrew Morton , Linus Torvalds , Ingo Molnar , Suparna Bhattacharya , Zach Brown , Benjamin LaHaise Subject: Re: [patch 13/13] signal/timer/event fds v9 - KAIO eventfd support example ... In-Reply-To: <461011E0.1020607@argo.co.il> Message-ID: References: <460FCA90.4000003@argo.co.il> <460FFD0F.7080107@argo.co.il> <461011E0.1020607@argo.co.il> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 1 Apr 2007, Avi Kivity wrote: > Davide Libenzi wrote: > > > > > I think it's a bit too fine grained, and a new system call (io_bindfd()?) > > > would be easier to use. In addition, you would move the eventfd_fget() > > > out of > > > the submission path. > > > > > > > IMO the cost of the eventfd_fget() (have you seen it?) is not worth adding a > > new syscall. > > > > There's an atomic op there (and another on the way out). Probably on a busy > cacheline. Still it's probably lost in the noise. > > Regardless of that, I think that specifying the fd per submission is wrong. > It feels like a setup thing that needs to be done once. We shouldn't skimp on > syscalls, especially on something as important as unifying the async event > model. For userspace that wants to do that (that is, having iocbs signaled to an eventfd), do not really matter much. They have their own iocb setup function and they'd simply set a flag more and set the resfd. The global setting may be good for some users, with others that may complain in having to create another ctx just to set an fd. Again, IMO is not worth a new API. What do other folks think? - Davide