From: Coly Li <i@coly.li>
To: Zhu Yanhai <zhu.yanhai@gmail.com>
Cc: linux-kernel@vger.kernel.org, bcrl@kvack.org,
viro@zeniv.linux.org.uk, linux-aio@kvack.org,
linux-fsdevel@vger.kernel.org, jaxboe@fusionio.com,
Zhu Yanhai <gaoyang.zyh@taobao.com>
Subject: Re: [PATCH][RFC] A readahead complete notify approach to implement buffer aio
Date: Fri, 04 Nov 2011 02:09:19 +0800 [thread overview]
Message-ID: <4EB2D8CF.2080108@coly.li> (raw)
In-Reply-To: <1320138024-10837-1-git-send-email-gaoyang.zyh@taobao.com>
On 2011年11月01日 17:00, Zhu Yanhai Wrote:
> 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 baiocb, so I just put it into struct task_struct and
> refer it by current() as a workaround.
>
> * the do_baio_read() routine is heavily similar with do_generic_file_read(), but
> the latter is really hard to modify. I think we may stuff these code down into the
> readahead path to reduce code reduplication.
>
> Hopefully the explanations are clear enough and don't muddy the water any worse.
> I figure the code does need some better comments, and any suggestion are welcome.
>
> Signed-off-by: Zhu Yanhai <gaoyang.zyh@taobao.com>
>
> ---
> fs/aio.c | 319 ++++++++++++++++++++++++++++++++++++++++++-
> fs/buffer.c | 26 ++++-
> fs/mpage.c | 28 ++++-
> include/linux/aio.h | 9 ++
> include/linux/aio_abi.h | 1 +
> include/linux/blk_types.h | 2 +
> include/linux/buffer_head.h | 3 +
> include/linux/page-flags.h | 2 +
> include/linux/sched.h | 1 +
> 9 files changed, 386 insertions(+), 5 deletions(-)
>
Hmm, I don't see the usage from user space. Is it possible to post a demo code in user space, so people are able to
understand how to use/test your patch.
BTW, if there is any performance number, it should be interesting, too.
Thanks.
--
Coly Li
WARNING: multiple messages have this Message-ID (diff)
From: Coly Li <i@coly.li>
To: Zhu Yanhai <zhu.yanhai@gmail.com>
Cc: linux-kernel@vger.kernel.org, bcrl@kvack.org,
viro@zeniv.linux.org.uk, linux-aio@kvack.org,
linux-fsdevel@vger.kernel.org, jaxboe@fusionio.com,
Zhu Yanhai <gaoyang.zyh@taobao.com>
Subject: Re: [PATCH][RFC] A readahead complete notify approach to implement buffer aio
Date: Fri, 04 Nov 2011 02:09:19 +0800 [thread overview]
Message-ID: <4EB2D8CF.2080108@coly.li> (raw)
In-Reply-To: <1320138024-10837-1-git-send-email-gaoyang.zyh@taobao.com>
On 2011年11月01日 17:00, Zhu Yanhai Wrote:
> 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 baiocb, so I just put it into struct task_struct and
> refer it by current() as a workaround.
>
> * the do_baio_read() routine is heavily similar with do_generic_file_read(), but
> the latter is really hard to modify. I think we may stuff these code down into the
> readahead path to reduce code reduplication.
>
> Hopefully the explanations are clear enough and don't muddy the water any worse.
> I figure the code does need some better comments, and any suggestion are welcome.
>
> Signed-off-by: Zhu Yanhai <gaoyang.zyh@taobao.com>
>
> ---
> fs/aio.c | 319 ++++++++++++++++++++++++++++++++++++++++++-
> fs/buffer.c | 26 ++++-
> fs/mpage.c | 28 ++++-
> include/linux/aio.h | 9 ++
> include/linux/aio_abi.h | 1 +
> include/linux/blk_types.h | 2 +
> include/linux/buffer_head.h | 3 +
> include/linux/page-flags.h | 2 +
> include/linux/sched.h | 1 +
> 9 files changed, 386 insertions(+), 5 deletions(-)
>
Hmm, I don't see the usage from user space. Is it possible to post a demo code in user space, so people are able to
understand how to use/test your patch.
BTW, if there is any performance number, it should be interesting, too.
Thanks.
--
Coly Li
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2011-11-03 17:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-01 9:00 [PATCH][RFC] A readahead complete notify approach to implement buffer aio Zhu Yanhai
2011-11-01 9:00 ` Zhu Yanhai
2011-11-03 18:09 ` Coly Li [this message]
2011-11-03 18:09 ` Coly Li
2011-11-03 18:01 ` Jeff Moyer
2011-11-03 18:01 ` Jeff Moyer
2011-11-04 2:59 ` Shaohua Li
2011-11-04 2:59 ` Shaohua Li
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=4EB2D8CF.2080108@coly.li \
--to=i@coly.li \
--cc=bcrl@kvack.org \
--cc=gaoyang.zyh@taobao.com \
--cc=jaxboe@fusionio.com \
--cc=linux-aio@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zhu.yanhai@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.