Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Aug 2014 20:50:22 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        arch@freebsd.org
Subject:   Re: [CFT/review] new sendfile(2)
Message-ID:  <20140831165022.GE7693@FreeBSD.org>
In-Reply-To: <20140729232404.GF43962@funkthat.com>
References:  <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
  John-Mark,

On Tue, Jul 29, 2014 at 04:24:04PM -0700, John-Mark Gurney wrote:
J> Gleb Smirnoff wrote this message on Thu, May 29, 2014 at 14:20 +0400:
J> >   One of the approaches we are experimenting with is new sendfile(2)
J> > implementation, that doesn't block on the I/O done from the file
J> > descriptor.
J> 
J> I know this is a reply to an old message, but...

I am also sorry for late reply on late reply :)

J> How is this different from:
J>            SF_NODISKIO.  This flag causes any sendfile() call which would
J>            block on disk I/O to instead return EBUSY.  Busy servers may bene-
J>            fit by transferring requests that would block to a separate I/O
J>            worker thread.

It is very different. New sendfile(2) simply doesn't block and returns
success :) The I/O completes outside of syscall context.

J> > 1) Split of socket buffer sb_cc field into sb_acc and sb_ccc. Where
J> > sb_acc stands for "available character count" and sb_ccc is "claimed
J> > character count". This allows us to write a data to a socket, that is
J> > not ready yet. The data sits in the socket, consumes its space, and
J> > keeps itself in the right order with earlier or later writes to socket.
J> > But it can be send only after it is marked as ready. This change is
J> > split across many files.
J> 
J> This change really should be split out and possibly committed seperately
J> after a review by the proper people...

Of course. It actually makes 80% of the volume of the patch.

-- 
Totus tuus, Glebius.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140831165022.GE7693>