LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: David Miller <davem@davemloft.net>,
	Ulrich Drepper <drepper@redhat.com>,
	Andrew Morton <akpm@osdl.org>, netdev <netdev@vger.kernel.org>,
	Zach Brown <zach.brown@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	Chase Venters <chase.venters@clientec.com>,
	Johann Borck <johann.borck@densedata.com>,
	linux-kernel@vger.kernel.org, Jeff Garzik <jeff@garzik.org>,
	Jamal Hadi Salim <hadi@cyberus.ca>, Ingo Molnar <mingo@elte.hu>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [take33 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()).
Date: Fri, 19 Jan 2007 12:23:43 +0300	[thread overview]
Message-ID: <20070119092343.GA14605@2ka.mipt.ru> (raw)
In-Reply-To: <20070119062700.GA14705@in.ibm.com>

On Fri, Jan 19, 2007 at 11:57:00AM +0530, Suparna Bhattacharya (suparna@in.ibm.com) wrote:
> > > Since you are implementing new APIs here, have you considered doing an
> > > aio_sendfilev to be able to send a header with the data ?
> > 
> > It is doable, but why people do not like corking?
> > With Linux less than microsecond syscall overhead it is better and more
> > flexible solution, doesn't it?
> 
> That is what I used to think as well. However ...
> 
> The problem as I understand it now is not about bunching data together, but
> of ensuring some sort of atomicity between the header and the data, when
> there can be multiple outstanding aio requests on the same socket - i.e
> ensuring strict ordering without other data coming in between, when data
> to be sent is not already in cache, and in the meantime another sendfile
> or aio write requests comes in for the same socket. Without having to lock
> the socket when reading data from disk.

No, socket locking is not solution at all here.
But the same applies to header - it will be copied into socket queue,
then socket will be unlocked and populated VFS data will be put into
that queue too, but there is a window between socket unlock after header
copy and file data copy. If we will hold socket lock after header is
copied, it is possible to lock it for too long - bad sectors on disk,
and reading might take forever.

> There are alternate ways to address this, aio_sendfilev is one of the options
> I have heard people requesting.

I bet those people worked with different Unix systems, which have much
slower syscalls, so they combine several operations into one call.

Only from this perspective I see any benefit from having header in the
syscall related to file transfer. Since I already "optimized" open()
syscall into file sending, things can not became worse if I will put there
header pointer too. I will schedule new kevent release with this change
somewhere after current work on M-on-N threading model.

> Regards
> Suparna

-- 
	Evgeniy Polyakov

  reply	other threads:[~2007-01-19  9:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1315adqaa0591036@2ka.mipt.ru>
2007-01-17  6:30 ` [take33 0/10] kevent: Generic event handling mechanism Evgeniy Polyakov
2007-01-17  6:30   ` [take33 1/10] kevent: Description Evgeniy Polyakov
2007-01-17  6:30     ` [take33 2/10] kevent: Core files Evgeniy Polyakov
2007-01-17  6:30       ` [take33 3/10] kevent: poll/select() notifications Evgeniy Polyakov
2007-01-17  6:30         ` [take33 4/10] kevent: Socket notifications Evgeniy Polyakov
2007-01-17  6:30           ` [take33 5/10] kevent: Timer notifications Evgeniy Polyakov
2007-01-17  6:30             ` [take33 6/10] kevent: Pipe notifications Evgeniy Polyakov
2007-01-17  6:30               ` [take33 7/10] kevent: Signal notifications Evgeniy Polyakov
2007-01-17  6:30                 ` [take33 8/10] kevent: Kevent posix timer notifications Evgeniy Polyakov
2007-01-17  6:30                   ` [take33 9/10] kevent: Private userspace notifications Evgeniy Polyakov
2007-01-17  6:30                     ` [take33 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()) Evgeniy Polyakov
2007-01-17 13:51                       ` Suparna Bhattacharya
2007-01-17 14:39                         ` Evgeniy Polyakov
2007-01-19  6:27                           ` Suparna Bhattacharya
2007-01-19  9:23                             ` Evgeniy Polyakov [this message]
2007-01-25 13:48 ` [take34 0/10] kevent: Generic event handling mechanism Evgeniy Polyakov
2007-01-25 13:48   ` [take34 1/10] kevent: Description Evgeniy Polyakov
2007-01-25 13:48     ` [take34 2/10] kevent: Core files Evgeniy Polyakov
2007-01-25 13:48       ` [take34 3/10] kevent: poll/select() notifications Evgeniy Polyakov
2007-01-25 13:48         ` [take34 4/10] kevent: Socket notifications Evgeniy Polyakov
2007-01-25 13:48           ` [take34 5/10] kevent: Timer notifications Evgeniy Polyakov
2007-01-25 13:48             ` [take34 6/10] kevent: Pipe notifications Evgeniy Polyakov
2007-01-25 13:48               ` [take34 7/10] kevent: Signal notifications Evgeniy Polyakov
2007-01-25 13:48                 ` [take34 8/10] kevent: Kevent posix timer notifications Evgeniy Polyakov
2007-01-25 13:48                   ` [take34 9/10] kevent: Private userspace notifications Evgeniy Polyakov
2007-01-25 13:48                     ` [take34 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()) Evgeniy Polyakov
2007-01-25 22:56   ` [take34 0/10] kevent: Generic event handling mechanism Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070119092343.GA14605@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=akpm@osdl.org \
    --cc=chase.venters@clientec.com \
    --cc=davem@davemloft.net \
    --cc=drepper@redhat.com \
    --cc=hadi@cyberus.ca \
    --cc=hch@infradead.org \
    --cc=jeff@garzik.org \
    --cc=johann.borck@densedata.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=suparna@in.ibm.com \
    --cc=zach.brown@oracle.com \
    --subject='Re: [take33 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()).' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).