From owner-freebsd-current@FreeBSD.ORG Thu Jul 11 19:04:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82300B6; Thu, 11 Jul 2013 19:04:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 31E1A1FC8; Thu, 11 Jul 2013 19:04:59 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r6BJ4vVN084841; Thu, 11 Jul 2013 13:04:58 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: hacking - aio_sendfile() From: Scott Long In-Reply-To: <20130711184835.GS91021@kib.kiev.ua> Date: Thu, 11 Jul 2013 12:04:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <292A629B-7650-4845-83A2-E2C985D9C346@samsco.org> References: <20130711061753.GK91021@kib.kiev.ua> <20130711184835.GS91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:04:59 -0000 On Jul 11, 2013, at 11:48 AM, Konstantin Belousov = wrote: > On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: >>=20 >> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov = wrote: >>=20 >>> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: >>>> Hiya, >>>>=20 >>>> I've started writing an aio_sendfile() syscall. >>>>=20 >>>> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff >>>>=20 >>>> Yes, the diff is against -HEAD and not stable/9. >>>>=20 >>>> It's totally horrible, hackish and likely bad. I've only done some >>>> very, very basic testing to ensure it actually works; i haven't at = all >>>> stress tested it out yet. It's also very naive - I'm not at all = doing >>>> any checks to see whether I can short-cut to do the aio there and >>>> then; I'm always queuing the sendfile() op through the worker = threads. >>>> That's likely stupid and inefficient in a lot of cases, but it at >>>> least gets the syscall up and working. >>> Yes, it is naive, but for different reason. >>>=20 >>> The kern_sendfile() is synchronous function, it only completes after >>> the other end of the network communication allows it. This means >>> that calling kern_sendfile() from the aio thread blocks the thread >>> indefinitely by unbounded sleep. >>=20 >>=20 >> No, kern_sendfile is async unless you specify the SF_SYNC hack flag. >> Otherwise, it'll fill the socket buffer and then return immediately, = unless >> the socket buffer is full and the socket is set to blocking mode. = That's >> outside the scope, as I said in my previous email. >=20 > You do not understand what I said, please re-read both my mail and = code > before replying. Implementing aio_sendfile() as proposed would create > yet another possibility of indefinitely block all processes using aio. I'm lost, maybe I missed some emails? I see a set of emails where you = incorrectly state that kern_sendfile() will always call sbwait(), and then you = backtrack on that and claim that it's unacceptable to enforce that SS_NBIO be used for aio = operations. I apologize if I'm missing something here. Scott