<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.kernel.aio.general">
    <title>gmane.linux.kernel.aio.general</title>
    <link>http://blog.gmane.org/gmane.linux.kernel.aio.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3062"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3059"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3056"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3054"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3051"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3042"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3036"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3032"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3024"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3022"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/3019"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2980"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2975"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2967"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2966"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2954"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2951"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2949"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2940"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.aio.general/2938"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3062">
    <title>libaio status</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3062</link>
    <description>&lt;pre&gt;Hello. I'm looking for alternatives to do async I/O in Linux and it
looks like libaio is the only "native" way to do it, but the information
about it is really scarce and incomplete.

libaio website (if [1] is the website) looks outdated and have a lot of
broken links. The manpage footers says Linux 2.4 and I can't find any
mention about the restrictions mentioned in the website, so I don't know
if those restrictions are up to date and accurate.

I found this document [2], which so far looks like the most
comprehensive and up to date resource available, but again, being not an
"official" document, I'm not sure how accurate is it.

My feeling is libaio is only good to do O_DIRECT I/O on raw block
devices, but I needed for regular files in an ext4 filesystem (ideally
I shouldn't  impose a limitation on the filesystem to use, but I guess
I could do that if necessary). I need to do I/O in a server that needs
to have extremely low latency, so I can't afford any type of blocking.
Using threads is not a viable opti&lt;/pre&gt;</description>
    <dc:creator>Leandro Lucarella</dc:creator>
    <dc:date>2012-05-15T13:46:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3059">
    <title>What's the usage of io_setup?</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3059</link>
    <description>&lt;pre&gt;Hi,

I'm new to libaio, and have some question about io_setup.

I walked through the code of io_setup, and found that it frees the ioctx
after obtain ioctx-&amp;gt;user_id. So the caller just gets a handle for a freed
ioctx, right?

So what's the usage of io_submit in real word applications?

thanks,
Ryan
&lt;/pre&gt;</description>
    <dc:creator>Ryan Wang</dc:creator>
    <dc:date>2012-04-19T01:58:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3056">
    <title>Where can I find the git tree for libaio?</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3056</link>
    <description>&lt;pre&gt;Hi,

I'm studying libaio recently, and now I want to get the upstream libaio.
I wonder where can I find the git tree for libaio, please?

thanks,
Ryan
&lt;/pre&gt;</description>
    <dc:creator>Ryan Wang</dc:creator>
    <dc:date>2012-04-16T06:18:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3054">
    <title>[patch] aio: change a stray spin_unlock_bh() to spin_unlock()</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3054</link>
    <description>&lt;pre&gt;We missed this spin_unlock_bh() when we removed the _bh from the other
locks in cb22bbe9f7 "aio: aio_nr_lock is taken only synchronously now"

Signed-off-by: Dan Carpenter &amp;lt;dan.carpenter&amp;lt; at &amp;gt;oracle.com&amp;gt;

diff --git a/fs/aio.c b/fs/aio.c
index 7b6b9d5..4f71627 100644
--- a/fs/aio.c
+++ b/fs/aio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -280,7 +280,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static struct kioctx *ioctx_alloc(unsigned nr_events)
 spin_lock(&amp;amp;aio_nr_lock);
 if (aio_nr + nr_events &amp;gt; aio_max_nr ||
     aio_nr + nr_events &amp;lt; aio_nr) {
-spin_unlock_bh(&amp;amp;aio_nr_lock);
+spin_unlock(&amp;amp;aio_nr_lock);
 goto out_cleanup;
 }
 aio_nr += ctx-&amp;gt;max_reqs;

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo&amp;lt; at &amp;gt;kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: &amp;lt;a href=mailto:"aart&amp;lt; at &amp;gt;kvack.org"&amp;gt;aart&amp;lt; at &amp;gt;kvack.org&amp;lt;/a&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Dan Carpenter</dc:creator>
    <dc:date>2012-03-20T13:09:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3051">
    <title>[patch] aio: wake up waiters when freeing unused kiocbs</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3051</link>
    <description>&lt;pre&gt;Hi,

Bart Van Assche reported a hung fio process when either hot-removing
storage or when interrupting the fio process itself.  The (pruned) call
trace for the latter looks like so:

fio             D 0000000000000001     0  6849   6848 0x00000004
 ffff880092541b88 0000000000000046 ffff880000000000 ffff88012fa11dc0
 ffff88012404be70 ffff880092541fd8 ffff880092541fd8 ffff880092541fd8
 ffff880128b894d0 ffff88012404be70 ffff880092541b88 000000018106f24d
Call Trace:
 [&amp;lt;ffffffff813b683f&amp;gt;] schedule+0x3f/0x60
 [&amp;lt;ffffffff813b68ef&amp;gt;] io_schedule+0x8f/0xd0
 [&amp;lt;ffffffff81174410&amp;gt;] wait_for_all_aios+0xc0/0x100
 [&amp;lt;ffffffff81175385&amp;gt;] exit_aio+0x55/0xc0
 [&amp;lt;ffffffff810413cd&amp;gt;] mmput+0x2d/0x110
 [&amp;lt;ffffffff81047c1d&amp;gt;] exit_mm+0x10d/0x130
 [&amp;lt;ffffffff810482b1&amp;gt;] do_exit+0x671/0x860
 [&amp;lt;ffffffff81048804&amp;gt;] do_group_exit+0x44/0xb0
 [&amp;lt;ffffffff81058018&amp;gt;] get_signal_to_deliver+0x218/0x5a0
 [&amp;lt;ffffffff81002065&amp;gt;] do_signal+0x65/0x700
 [&amp;lt;ffffffff81002785&amp;gt;] do_notify_resume+0x65/0x80
 [&amp;lt;ffffffff813c0333&amp;gt;] int_signal+0x12/0x17

The problem lies w&lt;/pre&gt;</description>
    <dc:creator>Jeff Moyer</dc:creator>
    <dc:date>2012-02-16T19:56:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3042">
    <title>[PATCH] AIO: Don't plug the I/O queue in do_io_submit()</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3042</link>
    <description>&lt;pre&gt;Asynchronous I/O latency to a solid-state disk greatly increased
between the 2.6.32 and 3.0 kernels. By removing the plug from
do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Signed-off-by: Dave Kleikamp &amp;lt;dave.kleikamp&amp;lt; at &amp;gt;oracle.com&amp;gt;
Cc: linux-aio&amp;lt; at &amp;gt;kvack.org
Cc: Chris Mason &amp;lt;chris.mason&amp;lt; at &amp;gt;oracle.com&amp;gt;
Cc: Jens Axboe &amp;lt;axboe&amp;lt; at &amp;gt;kernel.dk&amp;gt;
Cc: Andi Kleen &amp;lt;ak&amp;lt; at &amp;gt;linux.intel.com&amp;gt;
Cc: Jeff Moyer &amp;lt;jmoyer&amp;lt; at &amp;gt;redhat.com&amp;gt;

diff --git a/fs/aio.c b/fs/aio.c
index 78c514c..d131a2c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1696,7 +1696,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; long do_io_submit(aio_context_t ctx_id, long nr,
 struct kioctx *ctx;
 long ret = 0;
 int i = 0;
-struct blk_plug plug;
 struct kiocb_batch batch;
 
 if (unlikely(nr &amp;lt; 0))
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1716,8 +1715,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; long do_io_submit(aio_context_t ctx_id, long nr,
 
 kiocb_batch_init(&amp;amp;batch, nr);
 
-blk_start_plug(&amp;amp;plug);
-
 /*
  * AKPM: should this return a partial result if some of the IOs were
  * succe&lt;/pre&gt;</description>
    <dc:creator>Dave Kleikamp</dc:creator>
    <dc:date>2011-12-13T21:44:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3036">
    <title>AIO kernel.org websites</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3036</link>
    <description>&lt;pre&gt;Hi,

I'm trying to find the correct websites for the AIO project. I've
tried a few kernel.org addresses, without any luck:

  (main page) http://www.kernel.org/pub/linux/libs/aio/

  (userspace GIT) git://git.kernel.org/pub/scm/libs/libaio/libaio.git

  (userspace FTP) ftp://ftp.kernel.org/pub/linux/libs/aio/

Should these addresses be working after September's kernel.org
infrastructure changes?

Best regards,
Dan Cecile

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo&amp;lt; at &amp;gt;kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: &amp;lt;a href=mailto:"aart&amp;lt; at &amp;gt;kvack.org"&amp;gt;aart&amp;lt; at &amp;gt;kvack.org&amp;lt;/a&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Dan Cecile</dc:creator>
    <dc:date>2011-11-26T03:05:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3032">
    <title>[PATCH][RFC] A readahead complete notify approach to implement buffer aio</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3032</link>
    <description>&lt;pre&gt;The current libaio/aio has to be Direct-IO, otherwise it falls back into sync IO.
However, the aio core has already been asychronous naturally. This patch adds a complete
notify mechanism to implement buffer aio, the main idea is to readahead()-like in
io_submit(), counts the non-uptodated pages assocaiated with each iocb, then put each ref
in the bio complete path just before unlock_page(), and hook them on to the aio ring buffer
finally when the ref drops to zero. In io_getevents(), we call vfs_read() as a safe net
since there is still little possibility that the pages had brought in were reclaimed
between io_submit() and io_getevents().

I have tested this patch for a while, for the small size random io request, its
performance is more or less the same with the traditional aio, for the big io request,
the overhead of one extra memory copy arises.

I think so far it has at least below obvious drawbacks,

* mpage_readpage() is a really narrow interface, I have no way to pass down
the new control struct baio&lt;/pre&gt;</description>
    <dc:creator>Zhu Yanhai</dc:creator>
    <dc:date>2011-11-01T09:00:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3024">
    <title>blocking io_submit</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3024</link>
    <description>&lt;pre&gt;I've just realized the magnitude of the blocking
io_submit().

In my test [1], run on ubuntu 11.04, the majority of
the jobs submitted in io_submit are complete by the
time it returns. i.e. the level of asynchrony is fairly
low (for being an async. API).

Graphing the output [2] shows that the test spends essentially
all its time blocked by io_submit (as opposed to waiting
for completion events).

My attempt as a (user-level) work-around is to spawn a few
threads who spend their time submitting jobs. At least
my main disk thread won't get blocked, and I can react to
completion events much sooner. It also lets me submit jobs
sooner, by submitting from more than one thread.

Are there any caveats with this approach?

Does anyone have a better or different idea of ways to
work around this problem?

thanks,
&lt;/pre&gt;</description>
    <dc:creator>arvid&lt; at &gt;cs.umu.se</dc:creator>
    <dc:date>2011-09-23T02:25:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3022">
    <title>[patch, v3] aio: allocate kiocbs in batches</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3022</link>
    <description>&lt;pre&gt;Hi,

In testing aio on a fast storage device, I found that the context lock
takes up a fair amount of cpu time in the I/O submission path.  The
reason is that we take it for every I/O submitted (see __aio_get_req).
Since we know how many I/Os are passed to io_submit, we can preallocate
the kiocbs in batches, reducing the number of times we take and release
the lock.  In my testing, I was able to reduce the amount of time spent
in _raw_spin_lock_irq by .56% (average of 3 runs).  The command I used
to test this was:
   aio-stress -O -o 2 -o 3 -r 8 -d 128 -b 32 -i 32 -s 16384 &amp;lt;dev&amp;gt;

I also tested the patch with various numbers of events passed to
io_submit, and I ran the xfstests aio group of tests to ensure I didn't
break anything.

Signed-off-by: Jeff Moyer &amp;lt;jmoyer&amp;lt; at &amp;gt;redhat.com&amp;gt;

---
Changes from v2 -&amp;gt; v3:
- got rid of an extraneous structure member in the kiocb_batch.
- fixed up some haphazard variable types
- fixed a build warning

Changes from rfc -&amp;gt; v2:
- folded in akpm's incremental patch which fixes codin&lt;/pre&gt;</description>
    <dc:creator>Jeff Moyer</dc:creator>
    <dc:date>2011-09-22T16:41:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/3019">
    <title>[patch, v2] aio: allocate kiocbs in batches</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/3019</link>
    <description>&lt;pre&gt;Hi,

In testing aio on a fast storage device, I found that the context lock
takes up a fair amount of cpu time in the I/O submission path.  The
reason is that we take it for every I/O submitted (see __aio_get_req).
Since we know how many I/Os are passed to io_submit, we can preallocate
the kiocbs in batches, reducing the number of times we take and release
the lock.  In my testing, I was able to reduce the amount of time spent
in _raw_spin_lock_irq by .56% (average of 3 runs).  The command I used
to test this was:
   aio-stress -O -o 2 -o 3 -r 8 -d 128 -b 32 -i 32 -s 16384 &amp;lt;dev&amp;gt;

I also tested the patch with various numbers of events passed to
io_submit, and I ran the xfstests aio group of tests to ensure I didn't
break anything.

Signed-off-by: Jeff Moyer &amp;lt;jmoyer&amp;lt; at &amp;gt;redhat.com&amp;gt;

---
Changes from rfc -&amp;gt; v2:
- folded in akpm's incremental patch which fixes coding style and
  variable names
- tried to clarify a comment about a starvation case
- fixed up my breaking of the handling of that starvation case
- moved &lt;/pre&gt;</description>
    <dc:creator>Jeff Moyer</dc:creator>
    <dc:date>2011-09-21T17:16:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2980">
    <title>io_getevents() segfaults</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2980</link>
    <description>&lt;pre&gt;Hi!
I've been fixing libaio tests in LTP and found that io_getevents() may
segfault on random ctx.

The manual however says that we should get EINVAL in this case.

The cause for this is code in io_getevents() that dereferences ctx to
check for empty queue.

I've been told by Jeff that this code was flawed and not really
implemented anyway so attached patch simply removes it.

&lt;/pre&gt;</description>
    <dc:creator>Cyril Hrubis</dc:creator>
    <dc:date>2011-03-23T17:10:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2975">
    <title>[PATCH] aio: Wake all waiters when destroying ctx</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2975</link>
    <description>&lt;pre&gt;From: Roland Dreier &amp;lt;roland&amp;lt; at &amp;gt;purestorage.com&amp;gt;

The test program below will hang because io_getevents() uses
add_wait_queue_exclusive(), which means the wake_up() in io_destroy()
only wakes up one of the threads.  Fix this by using wake_up_all() in
the aio code paths where we want to make sure no one gets stuck.

// t.c -- compile with gcc -lpthread -laio t.c

#include &amp;lt;libaio.h&amp;gt;
#include &amp;lt;pthread.h&amp;gt;
#include &amp;lt;stdio.h&amp;gt;
#include &amp;lt;unistd.h&amp;gt;

static const int nthr = 2;

void *getev(void *ctx)
{
struct io_event ev;
io_getevents(ctx, 1, 1, &amp;amp;ev, NULL);
printf("io_getevents returned\n");
return NULL;
}

int main(int argc, char *argv[])
{
io_context_t ctx = 0;
pthread_t thread[nthr];
int i;

io_setup(1024, &amp;amp;ctx);

for (i = 0; i &amp;lt; nthr; ++i)
pthread_create(&amp;amp;thread[i], NULL, getev, ctx);

sleep(1);

io_destroy(ctx);

for (i = 0; i &amp;lt; nthr; ++i)
pthread_join(thread[i], NULL);

return 0;
}

Cc: &amp;lt;stable&amp;lt; at &amp;gt;kernel.org&amp;gt;
Signed-off-by: Roland Dreier &amp;lt;roland&amp;lt; at &amp;gt;purestorage.com&amp;gt;
---
 fs/aio.&lt;/pre&gt;</description>
    <dc:creator>Roland Dreier</dc:creator>
    <dc:date>2011-03-11T05:55:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2967">
    <title>The program.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2967</link>
    <description>&lt;pre&gt;Forgot to attach the program.
Please this program could be much better, the checking of errors like
ENOMEM could be better. I know.
But it does what it's written for. Do aio writes to an ordinary file
at a non aligned offset.

Stef
&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2011-01-31T09:47:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2966">
    <title>Some questions.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2966</link>
    <description>&lt;pre&gt;Hello,

as I've already mentioned here, I'm working on a fuse fs, and want to
make it work with aio.

I've some questions:

a. The aiocp example is a very good example. It's much better than the
aiocp in the man file of io, which totallly does not mention the
alignment.
My advice is to replace that. I've been trying to make aio work for
weeks now, and it's very frustating to not find the right
documentation. Just some days ago I first got the idea how important
the alignment is, when doing aio. The manpage should mention that.

About alignment, Jeff Moyer told me that when reading or writing from
a sata block device, the value alignment is the (logical) blocksize,
which you can detect with BLKSSZGET.
Isn't it the same value when doing a stavfs? My fs can do this once
for every underlying fs/blockdevice and can get this value once and
can store this value for later use, in stead of doing this every time
when doing an aio.

b. When looking at the aiocp example, at the start an array of iocb is
initialised :

i&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2011-01-31T09:34:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2954">
    <title>Problem using compile option -D_FILE_OFFSET_BITS=64.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2954</link>
    <description>&lt;pre&gt;Hi,

I'm trying to make my fuse fs use aio.

I've sent an email about this earlier to this list.

Now I've written a small test program to try to test the aio in combination with
signals and epoll.

This program works very good, at least when it's compiled like:


gcc -Wall -lrt testsignal.c -o testsignal


It's a advanced version of the test program found in the manpage of signalfd.

now test it:

./testsignal
mainloop: adding signalfd 4 to epoll
^CGot SIGINT: start the test aio read.


the progress in logfile:

Jan 28 11:58:08 clfs20091030 testsignal: aio_read_file
Jan 28 11:58:08 clfs20091030 testsignal: aio_read return: 0
Jan 28 11:58:08 clfs20091030 testsignal: mainloop aio read, no error,
nbytes: 14196767
Jan 28 11:58:08 clfs20091030 testsignal: aio_write_file
Jan 28 11:58:08 clfs20091030 testsignal: aio_write return: 0
Jan 28 11:58:08 clfs20091030 testsignal: mainloop aio write, no error,
nbytes: 14196767


This is as expected.

Now when I compile it using the -D_FILE_OFFSET_BITS=64

the same logoutpu&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2011-01-28T11:57:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2951">
    <title>problem using aio in fuse fs.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2951</link>
    <description>&lt;pre&gt;Hi,

I'm writing a fuse fs, fuse-workspace, which helps to create a
userfriendly, effective and powerfull layer for the average user. See:


http://linux.bononline.nl/wiki/index.php/Changes_and_issues

for changes and recent screenshots.

Mainpage:

http://linux.bononline.nl/wiki/index.php/Mount.md5key


Well the fuse-fs is the cosmetic layer, especially when in "GoboLinux" mode.
Blocking behaviour is very unwanted, cause this will block every app
running in userspace, wanting to do some io.
And then I mean every io.

Read and writes at this moment are blocking.


Now FUSE offers a construction to handle aio very easy.
By using a single thead, and in the mainloop a epoll instance,
watching standard the fuse fd for incoming fs events, like the call
getattr, open and read.
Now the processing of this request is done in a fuse fs specific call.
When ready it will send the results back using fuse_reply, using the
request handle to indentify it.


Now using aio here is very possible by:

a. add an eventfd to the l&lt;/pre&gt;</description>
    <dc:creator>Stef Bon</dc:creator>
    <dc:date>2011-01-26T12:02:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2949">
    <title>[patch] aio: remove unused function, aio_run_iocbs</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2949</link>
    <description>&lt;pre&gt;Hi,

aio_run_iocbs is not used at all, so get rid of it.

Signed-off-by: Jeff Moyer &amp;lt;jmoyer&amp;lt; at &amp;gt;redhat.com&amp;gt;

diff --git a/fs/aio.c b/fs/aio.c
index 8c8f6c5..6ca2f96 100644
--- a/fs/aio.c
+++ b/fs/aio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -798,30 +798,14 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void aio_queue_work(struct kioctx * ctx)
 queue_delayed_work(aio_wq, &amp;amp;ctx-&amp;gt;wq, timeout);
 }
 
-
 /*
- * aio_run_iocbs:
+ * aio_run_all_iocbs:
  * Process all pending retries queued on the ioctx
- * run list.
+ * run list, and keep running them until the list
+ * stays empty.
  * Assumes it is operating within the aio issuer's mm
  * context.
  */
-static inline void aio_run_iocbs(struct kioctx *ctx)
-{
-int requeue;
-
-spin_lock_irq(&amp;amp;ctx-&amp;gt;ctx_lock);
-
-requeue = __aio_run_iocbs(ctx);
-spin_unlock_irq(&amp;amp;ctx-&amp;gt;ctx_lock);
-if (requeue)
-aio_queue_work(ctx);
-}
-
-/*
- * just like aio_run_iocbs, but keeps running them until
- * the list stays empty
- */
 static inline void aio_run_all_iocbs(struct kioctx *ctx)
 {
 spin_lock_irq(&amp;amp;ctx-&amp;gt;ctx_lock);

--
To unsubscribe, send a message&lt;/pre&gt;</description>
    <dc:creator>Jeff Moyer</dc:creator>
    <dc:date>2011-01-05T21:19:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2940">
    <title>[PATCH] aio: remove unnecessary check</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2940</link>
    <description>&lt;pre&gt;'nr &amp;gt;= min_nr &amp;gt;= 0' always satisfies 'nr &amp;gt;= 0' so the check is unnecesary.

Signed-off-by: Namhyung Kim &amp;lt;namhyung&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/aio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index c56153f5f73e..45766460fa57 100644
--- a/fs/aio.c
+++ b/fs/aio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1839,7 +1839,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
 long ret = -EINVAL;
 
 if (likely(ioctx)) {
-if (likely(min_nr &amp;lt;= nr &amp;amp;&amp;amp; min_nr &amp;gt;= 0 &amp;amp;&amp;amp; nr &amp;gt;= 0))
+if (likely(min_nr &amp;lt;= nr &amp;amp;&amp;amp; min_nr &amp;gt;= 0))
 ret = read_events(ioctx, min_nr, nr, events, timeout);
 put_ioctx(ioctx);
 }
&lt;/pre&gt;</description>
    <dc:creator>Namhyung Kim</dc:creator>
    <dc:date>2010-12-16T09:09:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2938">
    <title>[PATCH] aio: using hash table for active requests</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2938</link>
    <description>&lt;pre&gt;This patch remove a TODO in fs/aio.c, that is to use hash table for active requests.

I prefer add an iocb at tail of collision chain, so I do not use hlist here.

Signed-off-by: Li Yu &amp;lt;raise.sail&amp;lt; at &amp;gt;gmail.com&amp;gt;
---

 fs/aio.c            |   90 ++++++++++++++++++++++++++++++++++++++--------------
 include/linux/aio.h |    2 -
 2 files changed, 68 insertions(+), 24 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 8c8f6c5..fee2aa3 100644
--- a/fs/aio.c
+++ b/fs/aio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -65,6 +65,15 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static DECLARE_WORK(fput_work, aio_fput_routine);
 static DEFINE_SPINLOCK(fput_lock);
 static LIST_HEAD(fput_head);
 
+#if BITS_PER_LONG == 64
+#define AIO_ACTREQ_BUCKETS_SHIFT36
+#elif BITS_PER_LONG == 32
+#define AIO_ACTREQ_BUCKETS_SHIFT        24
+#endif
+
+/* AIO_ACTREQ_BUCKETS must be power of 2 */
+#define AIO_ACTREQ_BUCKETS(2*PAGE_SIZE/sizeof(struct list_head))
+
 #define AIO_BATCH_HASH_BITS3 /* allocated on-stack, so don't go crazy */
 #define AIO_BATCH_HASH_SIZE(1 &amp;lt;&amp;lt; AIO_BATCH_HASH_BITS)
 struct aio_batch_entry {
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt;&lt;/pre&gt;</description>
    <dc:creator>Li Yu</dc:creator>
    <dc:date>2010-12-15T03:03:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.aio.general/2936">
    <title>[PATCH] aio: check return value of create_workqueue()</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.aio.general/2936</link>
    <description>&lt;pre&gt;Signed-off-by: Namhyung Kim &amp;lt;namhyung&amp;lt; at &amp;gt;gmail.com&amp;gt;
---
 fs/aio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 8c8f6c5b6d79..c56153f5f73e 100644
--- a/fs/aio.c
+++ b/fs/aio.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -87,7 +87,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int __init aio_setup(void)
 
 aio_wq = create_workqueue("aio");
 abe_pool = mempool_create_kmalloc_pool(1, sizeof(struct aio_batch_entry));
-BUG_ON(!abe_pool);
+BUG_ON(!aio_wq || !abe_pool);
 
 pr_debug("aio_setup: sizeof(struct page) = %d\n", (int)sizeof(struct page));
 
&lt;/pre&gt;</description>
    <dc:creator>Namhyung Kim</dc:creator>
    <dc:date>2010-12-13T15:06:25</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.kernel.aio.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.kernel.aio.general</link>
  </textinput>
</rdf:RDF>

