2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* An async IO implementation for Linux
|
|
|
|
* Written by Benjamin LaHaise <bcrl@kvack.org>
|
|
|
|
*
|
|
|
|
* Implements an efficient asynchronous io interface.
|
|
|
|
*
|
|
|
|
* Copyright 2000, 2001, 2002 Red Hat, Inc. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* See ../COPYING for licensing terms.
|
|
|
|
*/
|
2013-05-08 06:18:35 +07:00
|
|
|
#define pr_fmt(fmt) "%s: " fmt, __func__
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/time.h>
|
|
|
|
#include <linux/aio_abi.h>
|
2011-11-17 11:57:37 +07:00
|
|
|
#include <linux/export.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/syscalls.h>
|
2009-10-29 19:59:26 +07:00
|
|
|
#include <linux/backing-dev.h>
|
2006-10-01 13:28:46 +07:00
|
|
|
#include <linux/uio.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/mman.h>
|
2009-09-22 07:03:51 +07:00
|
|
|
#include <linux/mmu_context.h>
|
2013-04-26 07:58:39 +07:00
|
|
|
#include <linux/percpu.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/timer.h>
|
|
|
|
#include <linux/aio.h>
|
|
|
|
#include <linux/highmem.h>
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/security.h>
|
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:23:21 +07:00
|
|
|
#include <linux/eventfd.h>
|
2009-10-03 05:57:36 +07:00
|
|
|
#include <linux/blkdev.h>
|
2010-05-27 04:44:26 +07:00
|
|
|
#include <linux/compat.h>
|
2013-07-16 16:56:16 +07:00
|
|
|
#include <linux/migrate.h>
|
|
|
|
#include <linux/ramfs.h>
|
2013-05-29 05:14:48 +07:00
|
|
|
#include <linux/percpu-refcount.h>
|
2013-09-17 21:18:25 +07:00
|
|
|
#include <linux/mount.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
#include <asm/kmap_types.h>
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
|
2013-06-19 18:26:04 +07:00
|
|
|
#include "internal.h"
|
|
|
|
|
2013-05-08 06:18:33 +07:00
|
|
|
#define AIO_RING_MAGIC 0xa10a10a1
|
|
|
|
#define AIO_RING_COMPAT_FEATURES 1
|
|
|
|
#define AIO_RING_INCOMPAT_FEATURES 0
|
|
|
|
struct aio_ring {
|
|
|
|
unsigned id; /* kernel internal index number */
|
|
|
|
unsigned nr; /* number of io_events */
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
unsigned head; /* Written to by userland or under ring_lock
|
|
|
|
* mutex by aio_read_events_ring(). */
|
2013-05-08 06:18:33 +07:00
|
|
|
unsigned tail;
|
|
|
|
|
|
|
|
unsigned magic;
|
|
|
|
unsigned compat_features;
|
|
|
|
unsigned incompat_features;
|
|
|
|
unsigned header_length; /* size of aio_ring */
|
|
|
|
|
|
|
|
|
|
|
|
struct io_event io_events[0];
|
|
|
|
}; /* 128 bytes + ring size */
|
|
|
|
|
|
|
|
#define AIO_RING_PAGES 8
|
|
|
|
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
struct kioctx_table {
|
|
|
|
struct rcu_head rcu;
|
|
|
|
unsigned nr;
|
|
|
|
struct kioctx *table[];
|
|
|
|
};
|
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
struct kioctx_cpu {
|
|
|
|
unsigned reqs_available;
|
|
|
|
};
|
|
|
|
|
2013-05-08 06:18:33 +07:00
|
|
|
struct kioctx {
|
2013-05-29 05:14:48 +07:00
|
|
|
struct percpu_ref users;
|
2013-05-08 06:18:41 +07:00
|
|
|
atomic_t dead;
|
2013-05-08 06:18:33 +07:00
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
struct percpu_ref reqs;
|
|
|
|
|
2013-05-08 06:18:33 +07:00
|
|
|
unsigned long user_id;
|
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
struct __percpu kioctx_cpu *cpu;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For percpu reqs_available, number of slots we move to/from global
|
|
|
|
* counter at a time:
|
|
|
|
*/
|
|
|
|
unsigned req_batch;
|
2013-05-08 06:18:51 +07:00
|
|
|
/*
|
|
|
|
* This is what userspace passed to io_setup(), it's not used for
|
|
|
|
* anything but counting against the global max_reqs quota.
|
|
|
|
*
|
2013-05-08 06:18:55 +07:00
|
|
|
* The real limit is nr_events - 1, which will be larger (see
|
2013-05-08 06:18:51 +07:00
|
|
|
* aio_setup_ring())
|
|
|
|
*/
|
2013-05-08 06:18:33 +07:00
|
|
|
unsigned max_reqs;
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
/* Size of ringbuffer, in units of struct io_event */
|
|
|
|
unsigned nr_events;
|
2013-05-08 06:18:33 +07:00
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
unsigned long mmap_base;
|
|
|
|
unsigned long mmap_size;
|
|
|
|
|
|
|
|
struct page **ring_pages;
|
|
|
|
long nr_pages;
|
|
|
|
|
2013-05-29 05:14:48 +07:00
|
|
|
struct work_struct free_work;
|
2013-05-08 06:18:56 +07:00
|
|
|
|
|
|
|
struct {
|
2013-04-26 07:58:39 +07:00
|
|
|
/*
|
|
|
|
* This counts the number of available slots in the ringbuffer,
|
|
|
|
* so we avoid overflowing it: it's decremented (if positive)
|
|
|
|
* when allocating a kiocb and incremented when the resulting
|
|
|
|
* io_event is pulled off the ringbuffer.
|
2013-04-26 07:58:39 +07:00
|
|
|
*
|
|
|
|
* We batch accesses to it with a percpu version.
|
2013-04-26 07:58:39 +07:00
|
|
|
*/
|
|
|
|
atomic_t reqs_available;
|
2013-05-08 06:18:56 +07:00
|
|
|
} ____cacheline_aligned_in_smp;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
spinlock_t ctx_lock;
|
|
|
|
struct list_head active_reqs; /* used for cancellation */
|
|
|
|
} ____cacheline_aligned_in_smp;
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
struct {
|
|
|
|
struct mutex ring_lock;
|
2013-05-08 06:18:56 +07:00
|
|
|
wait_queue_head_t wait;
|
|
|
|
} ____cacheline_aligned_in_smp;
|
2013-05-08 06:18:55 +07:00
|
|
|
|
|
|
|
struct {
|
|
|
|
unsigned tail;
|
|
|
|
spinlock_t completion_lock;
|
2013-05-08 06:18:56 +07:00
|
|
|
} ____cacheline_aligned_in_smp;
|
2013-05-08 06:18:55 +07:00
|
|
|
|
|
|
|
struct page *internal_pages[AIO_RING_PAGES];
|
2013-07-16 16:56:16 +07:00
|
|
|
struct file *aio_ring_file;
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
|
|
|
|
unsigned id;
|
2013-05-08 06:18:33 +07:00
|
|
|
};
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*------ sysctl variables----*/
|
2005-11-07 15:59:31 +07:00
|
|
|
static DEFINE_SPINLOCK(aio_nr_lock);
|
|
|
|
unsigned long aio_nr; /* current system wide number of aio requests */
|
|
|
|
unsigned long aio_max_nr = 0x10000; /* system wide maximum number of aio requests */
|
2005-04-17 05:20:36 +07:00
|
|
|
/*----end sysctl variables---*/
|
|
|
|
|
2006-12-07 11:33:20 +07:00
|
|
|
static struct kmem_cache *kiocb_cachep;
|
|
|
|
static struct kmem_cache *kioctx_cachep;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-09-17 21:18:25 +07:00
|
|
|
static struct vfsmount *aio_mnt;
|
|
|
|
|
|
|
|
static const struct file_operations aio_ring_fops;
|
|
|
|
static const struct address_space_operations aio_ctx_aops;
|
|
|
|
|
|
|
|
static struct file *aio_private_file(struct kioctx *ctx, loff_t nr_pages)
|
|
|
|
{
|
|
|
|
struct qstr this = QSTR_INIT("[aio]", 5);
|
|
|
|
struct file *file;
|
|
|
|
struct path path;
|
|
|
|
struct inode *inode = alloc_anon_inode(aio_mnt->mnt_sb);
|
2013-11-13 14:49:40 +07:00
|
|
|
if (IS_ERR(inode))
|
|
|
|
return ERR_CAST(inode);
|
2013-09-17 21:18:25 +07:00
|
|
|
|
|
|
|
inode->i_mapping->a_ops = &aio_ctx_aops;
|
|
|
|
inode->i_mapping->private_data = ctx;
|
|
|
|
inode->i_size = PAGE_SIZE * nr_pages;
|
|
|
|
|
|
|
|
path.dentry = d_alloc_pseudo(aio_mnt->mnt_sb, &this);
|
|
|
|
if (!path.dentry) {
|
|
|
|
iput(inode);
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
|
|
|
path.mnt = mntget(aio_mnt);
|
|
|
|
|
|
|
|
d_instantiate(path.dentry, inode);
|
|
|
|
file = alloc_file(&path, FMODE_READ | FMODE_WRITE, &aio_ring_fops);
|
|
|
|
if (IS_ERR(file)) {
|
|
|
|
path_put(&path);
|
|
|
|
return file;
|
|
|
|
}
|
|
|
|
|
|
|
|
file->f_flags = O_RDWR;
|
|
|
|
file->private_data = ctx;
|
|
|
|
return file;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct dentry *aio_mount(struct file_system_type *fs_type,
|
|
|
|
int flags, const char *dev_name, void *data)
|
|
|
|
{
|
|
|
|
static const struct dentry_operations ops = {
|
|
|
|
.d_dname = simple_dname,
|
|
|
|
};
|
|
|
|
return mount_pseudo(fs_type, "aio:", NULL, &ops, 0xa10a10a1);
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* aio_setup
|
|
|
|
* Creates the slab caches used by the aio routines, panic on
|
|
|
|
* failure as this is done early during the boot sequence.
|
|
|
|
*/
|
|
|
|
static int __init aio_setup(void)
|
|
|
|
{
|
2013-09-17 21:18:25 +07:00
|
|
|
static struct file_system_type aio_fs = {
|
|
|
|
.name = "aio",
|
|
|
|
.mount = aio_mount,
|
|
|
|
.kill_sb = kill_anon_super,
|
|
|
|
};
|
|
|
|
aio_mnt = kern_mount(&aio_fs);
|
|
|
|
if (IS_ERR(aio_mnt))
|
|
|
|
panic("Failed to create aio fs mount.");
|
|
|
|
|
2007-05-07 04:49:57 +07:00
|
|
|
kiocb_cachep = KMEM_CACHE(kiocb, SLAB_HWCACHE_ALIGN|SLAB_PANIC);
|
|
|
|
kioctx_cachep = KMEM_CACHE(kioctx,SLAB_HWCACHE_ALIGN|SLAB_PANIC);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("sizeof(struct page) = %zu\n", sizeof(struct page));
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2009-09-23 06:43:53 +07:00
|
|
|
__initcall(aio_setup);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-09-27 07:34:51 +07:00
|
|
|
static void put_aio_ring_file(struct kioctx *ctx)
|
|
|
|
{
|
|
|
|
struct file *aio_ring_file = ctx->aio_ring_file;
|
|
|
|
if (aio_ring_file) {
|
|
|
|
truncate_setsize(aio_ring_file->f_inode, 0);
|
|
|
|
|
|
|
|
/* Prevent further access to the kioctx from migratepages */
|
|
|
|
spin_lock(&aio_ring_file->f_inode->i_mapping->private_lock);
|
|
|
|
aio_ring_file->f_inode->i_mapping->private_data = NULL;
|
|
|
|
ctx->aio_ring_file = NULL;
|
|
|
|
spin_unlock(&aio_ring_file->f_inode->i_mapping->private_lock);
|
|
|
|
|
|
|
|
fput(aio_ring_file);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
static void aio_free_ring(struct kioctx *ctx)
|
|
|
|
{
|
2013-07-16 16:56:16 +07:00
|
|
|
int i;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* Disconnect the kiotx from the ring file. This prevents future
|
|
|
|
* accesses to the kioctx from page migration.
|
|
|
|
*/
|
|
|
|
put_aio_ring_file(ctx);
|
|
|
|
|
2013-07-16 16:56:16 +07:00
|
|
|
for (i = 0; i < ctx->nr_pages; i++) {
|
2013-12-22 05:56:08 +07:00
|
|
|
struct page *page;
|
2013-07-16 16:56:16 +07:00
|
|
|
pr_debug("pid(%d) [%d] page->count=%d\n", current->pid, i,
|
|
|
|
page_count(ctx->ring_pages[i]));
|
2013-12-22 05:56:08 +07:00
|
|
|
page = ctx->ring_pages[i];
|
|
|
|
if (!page)
|
|
|
|
continue;
|
|
|
|
ctx->ring_pages[i] = NULL;
|
|
|
|
put_page(page);
|
2013-07-16 16:56:16 +07:00
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-11-20 05:33:03 +07:00
|
|
|
if (ctx->ring_pages && ctx->ring_pages != ctx->internal_pages) {
|
2013-05-08 06:18:55 +07:00
|
|
|
kfree(ctx->ring_pages);
|
2013-11-20 05:33:03 +07:00
|
|
|
ctx->ring_pages = NULL;
|
|
|
|
}
|
2013-07-16 16:56:16 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
vma->vm_ops = &generic_file_vm_ops;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations aio_ring_fops = {
|
|
|
|
.mmap = aio_ring_mmap,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int aio_set_page_dirty(struct page *page)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-17 20:34:24 +07:00
|
|
|
#if IS_ENABLED(CONFIG_MIGRATION)
|
2013-07-16 16:56:16 +07:00
|
|
|
static int aio_migratepage(struct address_space *mapping, struct page *new,
|
|
|
|
struct page *old, enum migrate_mode mode)
|
|
|
|
{
|
2013-09-27 07:34:51 +07:00
|
|
|
struct kioctx *ctx;
|
2013-07-16 16:56:16 +07:00
|
|
|
unsigned long flags;
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
pgoff_t idx;
|
2013-07-16 16:56:16 +07:00
|
|
|
int rc;
|
|
|
|
|
2013-12-22 05:56:08 +07:00
|
|
|
rc = 0;
|
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* mapping->private_lock here protects against the kioctx teardown. */
|
2013-12-22 05:56:08 +07:00
|
|
|
spin_lock(&mapping->private_lock);
|
|
|
|
ctx = mapping->private_data;
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
if (!ctx) {
|
|
|
|
rc = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The ring_lock mutex. The prevents aio_read_events() from writing
|
|
|
|
* to the ring's head, and prevents page migration from mucking in
|
|
|
|
* a partially initialized kiotx.
|
|
|
|
*/
|
|
|
|
if (!mutex_trylock(&ctx->ring_lock)) {
|
|
|
|
rc = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
idx = old->index;
|
|
|
|
if (idx < (pgoff_t)ctx->nr_pages) {
|
|
|
|
/* Make sure the old page hasn't already been changed */
|
|
|
|
if (ctx->ring_pages[idx] != old)
|
|
|
|
rc = -EAGAIN;
|
2013-12-22 05:56:08 +07:00
|
|
|
} else
|
|
|
|
rc = -EINVAL;
|
|
|
|
|
|
|
|
if (rc != 0)
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
goto out_unlock;
|
2013-12-22 05:56:08 +07:00
|
|
|
|
2013-07-16 16:56:16 +07:00
|
|
|
/* Writeback must be complete */
|
|
|
|
BUG_ON(PageWriteback(old));
|
2013-12-22 05:56:08 +07:00
|
|
|
get_page(new);
|
2013-07-16 16:56:16 +07:00
|
|
|
|
2013-12-22 05:56:08 +07:00
|
|
|
rc = migrate_page_move_mapping(mapping, new, old, NULL, mode, 1);
|
2013-07-16 16:56:16 +07:00
|
|
|
if (rc != MIGRATEPAGE_SUCCESS) {
|
2013-12-22 05:56:08 +07:00
|
|
|
put_page(new);
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
goto out_unlock;
|
2013-07-16 16:56:16 +07:00
|
|
|
}
|
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* Take completion_lock to prevent other writes to the ring buffer
|
|
|
|
* while the old page is copied to the new. This prevents new
|
|
|
|
* events from being lost.
|
2013-09-27 07:34:51 +07:00
|
|
|
*/
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
spin_lock_irqsave(&ctx->completion_lock, flags);
|
|
|
|
migrate_page_copy(new, old);
|
|
|
|
BUG_ON(ctx->ring_pages[idx] != old);
|
|
|
|
ctx->ring_pages[idx] = new;
|
|
|
|
spin_unlock_irqrestore(&ctx->completion_lock, flags);
|
2013-07-16 16:56:16 +07:00
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* The old page is no longer accessible. */
|
|
|
|
put_page(old);
|
2013-12-22 05:56:08 +07:00
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&ctx->ring_lock);
|
|
|
|
out:
|
|
|
|
spin_unlock(&mapping->private_lock);
|
2013-07-16 16:56:16 +07:00
|
|
|
return rc;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2013-07-17 20:34:24 +07:00
|
|
|
#endif
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-07-16 16:56:16 +07:00
|
|
|
static const struct address_space_operations aio_ctx_aops = {
|
|
|
|
.set_page_dirty = aio_set_page_dirty,
|
2013-07-17 20:34:24 +07:00
|
|
|
#if IS_ENABLED(CONFIG_MIGRATION)
|
2013-07-16 16:56:16 +07:00
|
|
|
.migratepage = aio_migratepage,
|
2013-07-17 20:34:24 +07:00
|
|
|
#endif
|
2013-07-16 16:56:16 +07:00
|
|
|
};
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
static int aio_setup_ring(struct kioctx *ctx)
|
|
|
|
{
|
|
|
|
struct aio_ring *ring;
|
|
|
|
unsigned nr_events = ctx->max_reqs;
|
2013-05-08 06:18:25 +07:00
|
|
|
struct mm_struct *mm = current->mm;
|
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 03:11:12 +07:00
|
|
|
unsigned long size, unused;
|
2005-04-17 05:20:36 +07:00
|
|
|
int nr_pages;
|
2013-07-16 16:56:16 +07:00
|
|
|
int i;
|
|
|
|
struct file *file;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/* Compensate for the ring buffer's head/tail overlap entry */
|
|
|
|
nr_events += 2; /* 1 is required, 2 for good luck */
|
|
|
|
|
|
|
|
size = sizeof(struct aio_ring);
|
|
|
|
size += sizeof(struct io_event) * nr_events;
|
|
|
|
|
2013-07-16 16:56:16 +07:00
|
|
|
nr_pages = PFN_UP(size);
|
2005-04-17 05:20:36 +07:00
|
|
|
if (nr_pages < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-09-17 21:18:25 +07:00
|
|
|
file = aio_private_file(ctx, nr_pages);
|
2013-07-16 16:56:16 +07:00
|
|
|
if (IS_ERR(file)) {
|
|
|
|
ctx->aio_ring_file = NULL;
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
return -ENOMEM;
|
2013-07-16 16:56:16 +07:00
|
|
|
}
|
|
|
|
|
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 03:11:12 +07:00
|
|
|
ctx->aio_ring_file = file;
|
|
|
|
nr_events = (PAGE_SIZE * nr_pages - sizeof(struct aio_ring))
|
|
|
|
/ sizeof(struct io_event);
|
|
|
|
|
|
|
|
ctx->ring_pages = ctx->internal_pages;
|
|
|
|
if (nr_pages > AIO_RING_PAGES) {
|
|
|
|
ctx->ring_pages = kcalloc(nr_pages, sizeof(struct page *),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!ctx->ring_pages) {
|
|
|
|
put_aio_ring_file(ctx);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-16 16:56:16 +07:00
|
|
|
for (i = 0; i < nr_pages; i++) {
|
|
|
|
struct page *page;
|
|
|
|
page = find_or_create_page(file->f_inode->i_mapping,
|
|
|
|
i, GFP_HIGHUSER | __GFP_ZERO);
|
|
|
|
if (!page)
|
|
|
|
break;
|
|
|
|
pr_debug("pid(%d) page[%d]->count=%d\n",
|
|
|
|
current->pid, i, page_count(page));
|
|
|
|
SetPageUptodate(page);
|
|
|
|
SetPageDirty(page);
|
|
|
|
unlock_page(page);
|
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 03:11:12 +07:00
|
|
|
|
|
|
|
ctx->ring_pages[i] = page;
|
2013-07-16 16:56:16 +07:00
|
|
|
}
|
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 03:11:12 +07:00
|
|
|
ctx->nr_pages = i;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 03:11:12 +07:00
|
|
|
if (unlikely(i != nr_pages)) {
|
|
|
|
aio_free_ring(ctx);
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
return -ENOMEM;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ctx->mmap_size = nr_pages * PAGE_SIZE;
|
|
|
|
pr_debug("attempting mmap of %lu bytes\n", ctx->mmap_size);
|
2013-07-16 16:56:16 +07:00
|
|
|
|
2013-05-08 06:18:25 +07:00
|
|
|
down_write(&mm->mmap_sem);
|
2013-07-16 16:56:16 +07:00
|
|
|
ctx->mmap_base = do_mmap_pgoff(ctx->aio_ring_file, 0, ctx->mmap_size,
|
|
|
|
PROT_READ | PROT_WRITE,
|
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 03:11:12 +07:00
|
|
|
MAP_SHARED, 0, &unused);
|
|
|
|
up_write(&mm->mmap_sem);
|
2013-05-08 06:18:55 +07:00
|
|
|
if (IS_ERR((void *)ctx->mmap_base)) {
|
|
|
|
ctx->mmap_size = 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
aio_free_ring(ctx);
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
return -ENOMEM;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
pr_debug("mmap address: 0x%08lx\n", ctx->mmap_base);
|
2013-09-09 22:57:59 +07:00
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ctx->user_id = ctx->mmap_base;
|
|
|
|
ctx->nr_events = nr_events; /* trusted copy */
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ring = kmap_atomic(ctx->ring_pages[0]);
|
2005-04-17 05:20:36 +07:00
|
|
|
ring->nr = nr_events; /* user copy */
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
ring->id = ~0U;
|
2005-04-17 05:20:36 +07:00
|
|
|
ring->head = ring->tail = 0;
|
|
|
|
ring->magic = AIO_RING_MAGIC;
|
|
|
|
ring->compat_features = AIO_RING_COMPAT_FEATURES;
|
|
|
|
ring->incompat_features = AIO_RING_INCOMPAT_FEATURES;
|
|
|
|
ring->header_length = sizeof(struct aio_ring);
|
2011-11-25 22:14:27 +07:00
|
|
|
kunmap_atomic(ring);
|
2013-05-08 06:18:55 +07:00
|
|
|
flush_dcache_page(ctx->ring_pages[0]);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define AIO_EVENTS_PER_PAGE (PAGE_SIZE / sizeof(struct io_event))
|
|
|
|
#define AIO_EVENTS_FIRST_PAGE ((PAGE_SIZE - sizeof(struct aio_ring)) / sizeof(struct io_event))
|
|
|
|
#define AIO_EVENTS_OFFSET (AIO_EVENTS_PER_PAGE - AIO_EVENTS_FIRST_PAGE)
|
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn *cancel)
|
|
|
|
{
|
|
|
|
struct kioctx *ctx = req->ki_ctx;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&ctx->ctx_lock, flags);
|
|
|
|
|
|
|
|
if (!req->ki_list.next)
|
|
|
|
list_add(&req->ki_list, &ctx->active_reqs);
|
|
|
|
|
|
|
|
req->ki_cancel = cancel;
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&ctx->ctx_lock, flags);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kiocb_set_cancel_fn);
|
|
|
|
|
2013-05-14 04:45:08 +07:00
|
|
|
static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb)
|
2013-05-08 06:18:31 +07:00
|
|
|
{
|
2013-05-08 06:18:49 +07:00
|
|
|
kiocb_cancel_fn *old, *cancel;
|
2013-05-08 06:18:31 +07:00
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
/*
|
|
|
|
* Don't want to set kiocb->ki_cancel = KIOCB_CANCELLED unless it
|
|
|
|
* actually has a cancel function, hence the cmpxchg()
|
|
|
|
*/
|
|
|
|
|
|
|
|
cancel = ACCESS_ONCE(kiocb->ki_cancel);
|
|
|
|
do {
|
|
|
|
if (!cancel || cancel == KIOCB_CANCELLED)
|
2013-05-14 03:42:52 +07:00
|
|
|
return -EINVAL;
|
2013-05-08 06:18:31 +07:00
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
old = cancel;
|
|
|
|
cancel = cmpxchg(&kiocb->ki_cancel, old, KIOCB_CANCELLED);
|
|
|
|
} while (cancel != old);
|
2013-05-08 06:18:31 +07:00
|
|
|
|
2013-05-14 03:42:52 +07:00
|
|
|
return cancel(kiocb);
|
2013-05-08 06:18:31 +07:00
|
|
|
}
|
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
static void free_ioctx(struct work_struct *work)
|
2013-05-08 06:18:41 +07:00
|
|
|
{
|
2013-10-11 09:31:47 +07:00
|
|
|
struct kioctx *ctx = container_of(work, struct kioctx, free_work);
|
2013-04-26 07:58:39 +07:00
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
pr_debug("freeing %p\n", ctx);
|
2013-04-26 07:58:39 +07:00
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
aio_free_ring(ctx);
|
2013-04-26 07:58:39 +07:00
|
|
|
free_percpu(ctx->cpu);
|
2013-05-08 06:18:41 +07:00
|
|
|
kmem_cache_free(kioctx_cachep, ctx);
|
|
|
|
}
|
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
static void free_ioctx_reqs(struct percpu_ref *ref)
|
|
|
|
{
|
|
|
|
struct kioctx *ctx = container_of(ref, struct kioctx, reqs);
|
|
|
|
|
|
|
|
INIT_WORK(&ctx->free_work, free_ioctx);
|
|
|
|
schedule_work(&ctx->free_work);
|
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:41 +07:00
|
|
|
/*
|
|
|
|
* When this function runs, the kioctx has been removed from the "hash table"
|
|
|
|
* and ctx->users has dropped to 0, so we know no more kiocbs can be submitted -
|
|
|
|
* now it's safe to cancel any that need to be.
|
|
|
|
*/
|
2013-10-11 09:31:47 +07:00
|
|
|
static void free_ioctx_users(struct percpu_ref *ref)
|
2013-05-08 06:18:41 +07:00
|
|
|
{
|
2013-10-11 09:31:47 +07:00
|
|
|
struct kioctx *ctx = container_of(ref, struct kioctx, users);
|
2013-05-08 06:18:41 +07:00
|
|
|
struct kiocb *req;
|
|
|
|
|
|
|
|
spin_lock_irq(&ctx->ctx_lock);
|
|
|
|
|
|
|
|
while (!list_empty(&ctx->active_reqs)) {
|
|
|
|
req = list_first_entry(&ctx->active_reqs,
|
|
|
|
struct kiocb, ki_list);
|
|
|
|
|
|
|
|
list_del_init(&req->ki_list);
|
2013-05-14 04:45:08 +07:00
|
|
|
kiocb_cancel(ctx, req);
|
2013-05-08 06:18:41 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_irq(&ctx->ctx_lock);
|
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
percpu_ref_kill(&ctx->reqs);
|
|
|
|
percpu_ref_put(&ctx->reqs);
|
2013-05-08 06:18:41 +07:00
|
|
|
}
|
|
|
|
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
static int ioctx_add_table(struct kioctx *ctx, struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
unsigned i, new_nr;
|
|
|
|
struct kioctx_table *table, *old;
|
|
|
|
struct aio_ring *ring;
|
|
|
|
|
|
|
|
spin_lock(&mm->ioctx_lock);
|
2013-09-09 23:29:35 +07:00
|
|
|
rcu_read_lock();
|
2013-08-30 22:12:50 +07:00
|
|
|
table = rcu_dereference(mm->ioctx_table);
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
|
|
|
|
while (1) {
|
|
|
|
if (table)
|
|
|
|
for (i = 0; i < table->nr; i++)
|
|
|
|
if (!table->table[i]) {
|
|
|
|
ctx->id = i;
|
|
|
|
table->table[i] = ctx;
|
2013-09-09 23:29:35 +07:00
|
|
|
rcu_read_unlock();
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
spin_unlock(&mm->ioctx_lock);
|
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* While kioctx setup is in progress,
|
|
|
|
* we are protected from page migration
|
|
|
|
* changes ring_pages by ->ring_lock.
|
|
|
|
*/
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
ring = kmap_atomic(ctx->ring_pages[0]);
|
|
|
|
ring->id = ctx->id;
|
|
|
|
kunmap_atomic(ring);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
new_nr = (table ? table->nr : 1) * 4;
|
|
|
|
|
2013-09-09 23:29:35 +07:00
|
|
|
rcu_read_unlock();
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
spin_unlock(&mm->ioctx_lock);
|
|
|
|
|
|
|
|
table = kzalloc(sizeof(*table) + sizeof(struct kioctx *) *
|
|
|
|
new_nr, GFP_KERNEL);
|
|
|
|
if (!table)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
table->nr = new_nr;
|
|
|
|
|
|
|
|
spin_lock(&mm->ioctx_lock);
|
2013-09-09 23:29:35 +07:00
|
|
|
rcu_read_lock();
|
2013-08-30 22:12:50 +07:00
|
|
|
old = rcu_dereference(mm->ioctx_table);
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
|
|
|
|
if (!old) {
|
|
|
|
rcu_assign_pointer(mm->ioctx_table, table);
|
|
|
|
} else if (table->nr > old->nr) {
|
|
|
|
memcpy(table->table, old->table,
|
|
|
|
old->nr * sizeof(struct kioctx *));
|
|
|
|
|
|
|
|
rcu_assign_pointer(mm->ioctx_table, table);
|
|
|
|
kfree_rcu(old, rcu);
|
|
|
|
} else {
|
|
|
|
kfree(table);
|
|
|
|
table = old;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
static void aio_nr_sub(unsigned nr)
|
|
|
|
{
|
|
|
|
spin_lock(&aio_nr_lock);
|
|
|
|
if (WARN_ON(aio_nr - nr > aio_nr))
|
|
|
|
aio_nr = 0;
|
|
|
|
else
|
|
|
|
aio_nr -= nr;
|
|
|
|
spin_unlock(&aio_nr_lock);
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* ioctx_alloc
|
|
|
|
* Allocates and initializes an ioctx. Returns an ERR_PTR if it failed.
|
|
|
|
*/
|
|
|
|
static struct kioctx *ioctx_alloc(unsigned nr_events)
|
|
|
|
{
|
2013-05-08 06:18:25 +07:00
|
|
|
struct mm_struct *mm = current->mm;
|
2005-04-17 05:20:36 +07:00
|
|
|
struct kioctx *ctx;
|
2012-03-07 02:33:22 +07:00
|
|
|
int err = -ENOMEM;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
/*
|
|
|
|
* We keep track of the number of available ringbuffer slots, to prevent
|
|
|
|
* overflow (reqs_available), and we also use percpu counters for this.
|
|
|
|
*
|
|
|
|
* So since up to half the slots might be on other cpu's percpu counters
|
|
|
|
* and unavailable, double nr_events so userspace sees what they
|
|
|
|
* expected: additionally, we move req_batch slots to/from percpu
|
|
|
|
* counters at a time, so make sure that isn't 0:
|
|
|
|
*/
|
|
|
|
nr_events = max(nr_events, num_possible_cpus() * 4);
|
|
|
|
nr_events *= 2;
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* Prevent overflows */
|
|
|
|
if ((nr_events > (0x10000000U / sizeof(struct io_event))) ||
|
|
|
|
(nr_events > (0x10000000U / sizeof(struct kiocb)))) {
|
|
|
|
pr_debug("ENOMEM: nr_events too high\n");
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
2013-07-30 23:06:37 +07:00
|
|
|
if (!nr_events || (unsigned long)nr_events > (aio_max_nr * 2UL))
|
2005-04-17 05:20:36 +07:00
|
|
|
return ERR_PTR(-EAGAIN);
|
|
|
|
|
2007-02-10 16:45:03 +07:00
|
|
|
ctx = kmem_cache_zalloc(kioctx_cachep, GFP_KERNEL);
|
2005-04-17 05:20:36 +07:00
|
|
|
if (!ctx)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
ctx->max_reqs = nr_events;
|
|
|
|
|
|
|
|
spin_lock_init(&ctx->ctx_lock);
|
2013-05-08 06:18:49 +07:00
|
|
|
spin_lock_init(&ctx->completion_lock);
|
2013-05-08 06:18:55 +07:00
|
|
|
mutex_init(&ctx->ring_lock);
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* Protect against page migration throughout kiotx setup by keeping
|
|
|
|
* the ring_lock mutex held until setup is complete. */
|
|
|
|
mutex_lock(&ctx->ring_lock);
|
2005-04-17 05:20:36 +07:00
|
|
|
init_waitqueue_head(&ctx->wait);
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&ctx->active_reqs);
|
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
if (percpu_ref_init(&ctx->users, free_ioctx_users))
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (percpu_ref_init(&ctx->reqs, free_ioctx_reqs))
|
|
|
|
goto err;
|
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
ctx->cpu = alloc_percpu(struct kioctx_cpu);
|
|
|
|
if (!ctx->cpu)
|
2013-10-11 09:31:47 +07:00
|
|
|
goto err;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
err = aio_setup_ring(ctx);
|
|
|
|
if (err < 0)
|
2013-10-11 09:31:47 +07:00
|
|
|
goto err;
|
2013-04-26 07:58:39 +07:00
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
atomic_set(&ctx->reqs_available, ctx->nr_events - 1);
|
2013-04-26 07:58:39 +07:00
|
|
|
ctx->req_batch = (ctx->nr_events - 1) / (num_possible_cpus() * 4);
|
2013-07-31 21:34:18 +07:00
|
|
|
if (ctx->req_batch < 1)
|
|
|
|
ctx->req_batch = 1;
|
2013-04-26 07:58:39 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* limit the number of system wide aios */
|
2012-03-11 11:14:05 +07:00
|
|
|
spin_lock(&aio_nr_lock);
|
2013-07-30 23:06:37 +07:00
|
|
|
if (aio_nr + nr_events > (aio_max_nr * 2UL) ||
|
2012-03-11 11:10:35 +07:00
|
|
|
aio_nr + nr_events < aio_nr) {
|
2012-03-11 11:14:05 +07:00
|
|
|
spin_unlock(&aio_nr_lock);
|
2013-10-11 09:31:47 +07:00
|
|
|
err = -EAGAIN;
|
2013-12-04 17:19:06 +07:00
|
|
|
goto err_ctx;
|
2012-03-11 11:10:35 +07:00
|
|
|
}
|
|
|
|
aio_nr += ctx->max_reqs;
|
2012-03-11 11:14:05 +07:00
|
|
|
spin_unlock(&aio_nr_lock);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-12-22 03:49:28 +07:00
|
|
|
percpu_ref_get(&ctx->users); /* io_setup() will drop this ref */
|
|
|
|
percpu_ref_get(&ctx->reqs); /* free_ioctx_users() will drop this */
|
2013-05-29 05:14:48 +07:00
|
|
|
|
2013-08-06 00:21:43 +07:00
|
|
|
err = ioctx_add_table(ctx, mm);
|
|
|
|
if (err)
|
2013-10-11 09:31:47 +07:00
|
|
|
goto err_cleanup;
|
2013-08-06 00:21:43 +07:00
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* Release the ring_lock mutex now that all setup is complete. */
|
|
|
|
mutex_unlock(&ctx->ring_lock);
|
|
|
|
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("allocated ioctx %p[%ld]: mm=%p mask=0x%x\n",
|
2013-05-08 06:18:55 +07:00
|
|
|
ctx, ctx->user_id, mm, ctx->nr_events);
|
2005-04-17 05:20:36 +07:00
|
|
|
return ctx;
|
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
err_cleanup:
|
|
|
|
aio_nr_sub(ctx->max_reqs);
|
2013-12-04 17:19:06 +07:00
|
|
|
err_ctx:
|
|
|
|
aio_free_ring(ctx);
|
2013-10-11 09:31:47 +07:00
|
|
|
err:
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
mutex_unlock(&ctx->ring_lock);
|
2013-04-26 07:58:39 +07:00
|
|
|
free_percpu(ctx->cpu);
|
2013-10-11 09:31:47 +07:00
|
|
|
free_percpu(ctx->reqs.pcpu_count);
|
2013-05-29 05:14:48 +07:00
|
|
|
free_percpu(ctx->users.pcpu_count);
|
2005-04-17 05:20:36 +07:00
|
|
|
kmem_cache_free(kioctx_cachep, ctx);
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("error allocating ioctx %d\n", err);
|
2012-03-07 02:33:22 +07:00
|
|
|
return ERR_PTR(err);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:41 +07:00
|
|
|
/* kill_ioctx
|
|
|
|
* Cancels all outstanding aio requests on an aio context. Used
|
|
|
|
* when the processes owning a context have all exited to encourage
|
|
|
|
* the rapid destruction of the kioctx.
|
|
|
|
*/
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
static void kill_ioctx(struct mm_struct *mm, struct kioctx *ctx)
|
2013-05-08 06:18:41 +07:00
|
|
|
{
|
|
|
|
if (!atomic_xchg(&ctx->dead, 1)) {
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
struct kioctx_table *table;
|
|
|
|
|
|
|
|
spin_lock(&mm->ioctx_lock);
|
2013-09-09 23:29:35 +07:00
|
|
|
rcu_read_lock();
|
2013-08-30 22:12:50 +07:00
|
|
|
table = rcu_dereference(mm->ioctx_table);
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
|
|
|
|
WARN_ON(ctx != table->table[ctx->id]);
|
|
|
|
table->table[ctx->id] = NULL;
|
2013-09-09 23:29:35 +07:00
|
|
|
rcu_read_unlock();
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
spin_unlock(&mm->ioctx_lock);
|
|
|
|
|
2013-05-29 05:14:48 +07:00
|
|
|
/* percpu_ref_kill() will do the necessary call_rcu() */
|
|
|
|
wake_up_all(&ctx->wait);
|
2007-02-03 16:13:45 +07:00
|
|
|
|
2013-05-08 06:18:41 +07:00
|
|
|
/*
|
2013-06-13 04:04:59 +07:00
|
|
|
* It'd be more correct to do this in free_ioctx(), after all
|
|
|
|
* the outstanding kiocbs have finished - but by then io_destroy
|
|
|
|
* has already returned, so io_setup() could potentially return
|
|
|
|
* -EAGAIN with no ioctxs actually in use (as far as userspace
|
|
|
|
* could tell).
|
2013-05-08 06:18:41 +07:00
|
|
|
*/
|
2013-10-11 09:31:47 +07:00
|
|
|
aio_nr_sub(ctx->max_reqs);
|
2013-06-13 04:04:59 +07:00
|
|
|
|
|
|
|
if (ctx->mmap_size)
|
|
|
|
vm_munmap(ctx->mmap_base, ctx->mmap_size);
|
|
|
|
|
2013-05-29 05:14:48 +07:00
|
|
|
percpu_ref_kill(&ctx->users);
|
2013-05-08 06:18:41 +07:00
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* wait_on_sync_kiocb:
|
|
|
|
* Waits on the given sync kiocb to complete.
|
|
|
|
*/
|
2013-05-14 03:42:52 +07:00
|
|
|
ssize_t wait_on_sync_kiocb(struct kiocb *req)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2013-05-14 03:42:52 +07:00
|
|
|
while (!req->ki_ctx) {
|
2005-04-17 05:20:36 +07:00
|
|
|
set_current_state(TASK_UNINTERRUPTIBLE);
|
2013-05-14 03:42:52 +07:00
|
|
|
if (req->ki_ctx)
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
2007-10-17 13:27:20 +07:00
|
|
|
io_schedule();
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
__set_current_state(TASK_RUNNING);
|
2013-05-14 03:42:52 +07:00
|
|
|
return req->ki_user_data;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2009-09-23 06:43:53 +07:00
|
|
|
EXPORT_SYMBOL(wait_on_sync_kiocb);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:41 +07:00
|
|
|
/*
|
|
|
|
* exit_aio: called when the last user of mm goes away. At this point, there is
|
|
|
|
* no way for any new requests to be submited or any of the io_* syscalls to be
|
|
|
|
* called on the context.
|
|
|
|
*
|
|
|
|
* There may be outstanding kiocbs, but free_ioctx() will explicitly wait on
|
|
|
|
* them.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2008-02-08 19:19:52 +07:00
|
|
|
void exit_aio(struct mm_struct *mm)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
struct kioctx_table *table;
|
2008-12-09 14:11:22 +07:00
|
|
|
struct kioctx *ctx;
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
unsigned i = 0;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
rcu_read_lock();
|
|
|
|
table = rcu_dereference(mm->ioctx_table);
|
|
|
|
|
|
|
|
do {
|
|
|
|
if (!table || i >= table->nr) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
rcu_assign_pointer(mm->ioctx_table, NULL);
|
|
|
|
if (table)
|
|
|
|
kfree(table);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ctx = table->table[i++];
|
|
|
|
} while (!ctx);
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
2008-12-09 14:11:22 +07:00
|
|
|
|
2012-04-21 08:49:41 +07:00
|
|
|
/*
|
|
|
|
* We don't need to bother with munmap() here -
|
|
|
|
* exit_mmap(mm) is coming and it'll unmap everything.
|
|
|
|
* Since aio_free_ring() uses non-zero ->mmap_size
|
|
|
|
* as indicator that it needs to unmap the area,
|
|
|
|
* just set it to 0; aio_free_ring() is the only
|
|
|
|
* place that uses ->mmap_size, so it's safe.
|
|
|
|
*/
|
2013-05-08 06:18:55 +07:00
|
|
|
ctx->mmap_size = 0;
|
2013-05-08 06:18:41 +07:00
|
|
|
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
kill_ioctx(mm, ctx);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
static void put_reqs_available(struct kioctx *ctx, unsigned nr)
|
|
|
|
{
|
|
|
|
struct kioctx_cpu *kcpu;
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
kcpu = this_cpu_ptr(ctx->cpu);
|
|
|
|
|
|
|
|
kcpu->reqs_available += nr;
|
|
|
|
while (kcpu->reqs_available >= ctx->req_batch * 2) {
|
|
|
|
kcpu->reqs_available -= ctx->req_batch;
|
|
|
|
atomic_add(ctx->req_batch, &ctx->reqs_available);
|
|
|
|
}
|
|
|
|
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool get_reqs_available(struct kioctx *ctx)
|
|
|
|
{
|
|
|
|
struct kioctx_cpu *kcpu;
|
|
|
|
bool ret = false;
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
kcpu = this_cpu_ptr(ctx->cpu);
|
|
|
|
|
|
|
|
if (!kcpu->reqs_available) {
|
|
|
|
int old, avail = atomic_read(&ctx->reqs_available);
|
|
|
|
|
|
|
|
do {
|
|
|
|
if (avail < ctx->req_batch)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
old = avail;
|
|
|
|
avail = atomic_cmpxchg(&ctx->reqs_available,
|
|
|
|
avail, avail - ctx->req_batch);
|
|
|
|
} while (avail != old);
|
|
|
|
|
|
|
|
kcpu->reqs_available += ctx->req_batch;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = true;
|
|
|
|
kcpu->reqs_available--;
|
|
|
|
out:
|
|
|
|
preempt_enable();
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* aio_get_req
|
2013-05-14 03:42:52 +07:00
|
|
|
* Allocate a slot for an aio request.
|
|
|
|
* Returns NULL if no requests are free.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2013-05-08 06:18:53 +07:00
|
|
|
static inline struct kiocb *aio_get_req(struct kioctx *ctx)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2013-05-08 06:18:53 +07:00
|
|
|
struct kiocb *req;
|
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
if (!get_reqs_available(ctx))
|
2013-05-08 06:18:53 +07:00
|
|
|
return NULL;
|
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
req = kmem_cache_alloc(kiocb_cachep, GFP_KERNEL|__GFP_ZERO);
|
2005-04-17 05:20:36 +07:00
|
|
|
if (unlikely(!req))
|
2013-05-08 06:18:53 +07:00
|
|
|
goto out_put;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
percpu_ref_get(&ctx->reqs);
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
req->ki_ctx = ctx;
|
2011-11-03 03:40:10 +07:00
|
|
|
return req;
|
2013-05-08 06:18:53 +07:00
|
|
|
out_put:
|
2013-04-26 07:58:39 +07:00
|
|
|
put_reqs_available(ctx, 1);
|
2013-05-08 06:18:53 +07:00
|
|
|
return NULL;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:39 +07:00
|
|
|
static void kiocb_free(struct kiocb *req)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2013-05-08 06:18:37 +07:00
|
|
|
if (req->ki_filp)
|
|
|
|
fput(req->ki_filp);
|
2009-07-01 01:41:11 +07:00
|
|
|
if (req->ki_eventfd != NULL)
|
|
|
|
eventfd_ctx_put(req->ki_eventfd);
|
2005-04-17 05:20:36 +07:00
|
|
|
kmem_cache_free(kiocb_cachep, req);
|
|
|
|
}
|
|
|
|
|
2008-04-29 14:58:57 +07:00
|
|
|
static struct kioctx *lookup_ioctx(unsigned long ctx_id)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
struct aio_ring __user *ring = (void __user *)ctx_id;
|
2008-12-09 14:11:22 +07:00
|
|
|
struct mm_struct *mm = current->mm;
|
2009-03-19 07:04:21 +07:00
|
|
|
struct kioctx *ctx, *ret = NULL;
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
struct kioctx_table *table;
|
|
|
|
unsigned id;
|
|
|
|
|
|
|
|
if (get_user(id, &ring->id))
|
|
|
|
return NULL;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-12-09 14:11:22 +07:00
|
|
|
rcu_read_lock();
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
table = rcu_dereference(mm->ioctx_table);
|
2008-12-09 14:11:22 +07:00
|
|
|
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
if (!table || id >= table->nr)
|
|
|
|
goto out;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
ctx = table->table[id];
|
2013-08-08 05:23:48 +07:00
|
|
|
if (ctx && ctx->user_id == ctx_id) {
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
percpu_ref_get(&ctx->users);
|
|
|
|
ret = ctx;
|
|
|
|
}
|
|
|
|
out:
|
2008-12-09 14:11:22 +07:00
|
|
|
rcu_read_unlock();
|
2009-03-19 07:04:21 +07:00
|
|
|
return ret;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* aio_complete
|
|
|
|
* Called when the io request on the given iocb is complete.
|
|
|
|
*/
|
2013-05-08 06:18:29 +07:00
|
|
|
void aio_complete(struct kiocb *iocb, long res, long res2)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kioctx *ctx = iocb->ki_ctx;
|
|
|
|
struct aio_ring *ring;
|
2013-05-08 06:18:47 +07:00
|
|
|
struct io_event *ev_page, *event;
|
2005-04-17 05:20:36 +07:00
|
|
|
unsigned long flags;
|
2013-05-08 06:18:47 +07:00
|
|
|
unsigned tail, pos;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2005-11-14 07:07:33 +07:00
|
|
|
/*
|
|
|
|
* Special case handling for sync iocbs:
|
|
|
|
* - events go directly into the iocb for fast handling
|
|
|
|
* - the sync task with the iocb in its stack holds the single iocb
|
|
|
|
* ref, no other paths have a way to get another ref
|
|
|
|
* - the sync task helpfully left a reference to itself in the iocb
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
|
|
|
if (is_sync_kiocb(iocb)) {
|
|
|
|
iocb->ki_user_data = res;
|
2013-05-14 03:42:52 +07:00
|
|
|
smp_wmb();
|
|
|
|
iocb->ki_ctx = ERR_PTR(-EXDEV);
|
2005-04-17 05:20:36 +07:00
|
|
|
wake_up_process(iocb->ki_obj.tsk);
|
2013-05-08 06:18:29 +07:00
|
|
|
return;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
if (iocb->ki_list.next) {
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&ctx->ctx_lock, flags);
|
|
|
|
list_del(&iocb->ki_list);
|
|
|
|
spin_unlock_irqrestore(&ctx->ctx_lock, flags);
|
|
|
|
}
|
2013-05-08 06:18:39 +07:00
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
/*
|
|
|
|
* Add a completion event to the ring buffer. Must be done holding
|
2013-07-04 05:09:16 +07:00
|
|
|
* ctx->completion_lock to prevent other code from messing with the tail
|
2013-05-08 06:18:49 +07:00
|
|
|
* pointer since we might be called from irq context.
|
|
|
|
*/
|
|
|
|
spin_lock_irqsave(&ctx->completion_lock, flags);
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
tail = ctx->tail;
|
2013-05-08 06:18:47 +07:00
|
|
|
pos = tail + AIO_EVENTS_OFFSET;
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
if (++tail >= ctx->nr_events)
|
2005-05-01 22:59:15 +07:00
|
|
|
tail = 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ev_page = kmap_atomic(ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE]);
|
2013-05-08 06:18:47 +07:00
|
|
|
event = ev_page + pos % AIO_EVENTS_PER_PAGE;
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
event->obj = (u64)(unsigned long)iocb->ki_obj.user;
|
|
|
|
event->data = iocb->ki_user_data;
|
|
|
|
event->res = res;
|
|
|
|
event->res2 = res2;
|
|
|
|
|
2013-05-08 06:18:47 +07:00
|
|
|
kunmap_atomic(ev_page);
|
2013-05-08 06:18:55 +07:00
|
|
|
flush_dcache_page(ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE]);
|
2013-05-08 06:18:47 +07:00
|
|
|
|
|
|
|
pr_debug("%p[%u]: %p: %p %Lx %lx %lx\n",
|
2013-05-08 06:18:35 +07:00
|
|
|
ctx, tail, iocb, iocb->ki_obj.user, iocb->ki_user_data,
|
|
|
|
res, res2);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/* after flagging the request as done, we
|
|
|
|
* must never even look at it again
|
|
|
|
*/
|
|
|
|
smp_wmb(); /* make event visible before updating tail */
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ctx->tail = tail;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ring = kmap_atomic(ctx->ring_pages[0]);
|
2013-05-08 06:18:47 +07:00
|
|
|
ring->tail = tail;
|
2011-11-25 22:14:27 +07:00
|
|
|
kunmap_atomic(ring);
|
2013-05-08 06:18:55 +07:00
|
|
|
flush_dcache_page(ctx->ring_pages[0]);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:49 +07:00
|
|
|
spin_unlock_irqrestore(&ctx->completion_lock, flags);
|
|
|
|
|
2013-05-08 06:18:47 +07:00
|
|
|
pr_debug("added to ring %p at [%u]\n", iocb, tail);
|
2008-04-11 11:29:19 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if the user asked us to deliver the result through an
|
|
|
|
* eventfd. The eventfd_signal() function is safe to be called
|
|
|
|
* from IRQ context.
|
|
|
|
*/
|
2009-03-19 07:04:19 +07:00
|
|
|
if (iocb->ki_eventfd != NULL)
|
2008-04-11 11:29:19 +07:00
|
|
|
eventfd_signal(iocb->ki_eventfd, 1);
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* everything turned out well, dispose of the aiocb. */
|
2013-05-14 03:42:52 +07:00
|
|
|
kiocb_free(iocb);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
aio: bad AIO race in aio_complete() leads to process hang
My group ran into a AIO process hang on a 2.6.24 kernel with the process
sleeping indefinitely in io_getevents(2) waiting for the last wakeup to come
and it never would.
We ran the tests on x86_64 SMP. The hang only occurred on a Xeon box
("Clovertown") but not a Core2Duo ("Conroe"). On the Xeon, the L2 cache isn't
shared between all eight processors, but is L2 is shared between between all
two processors on the Core2Duo we use.
My analysis of the hang is if you go down to the second while-loop
in read_events(), what happens on processor #1:
1) add_wait_queue_exclusive() adds thread to ctx->wait
2) aio_read_evt() to check tail
3) if aio_read_evt() returned 0, call [io_]schedule() and sleep
In aio_complete() with processor #2:
A) info->tail = tail;
B) waitqueue_active(&ctx->wait)
C) if waitqueue_active() returned non-0, call wake_up()
The way the code is written, step 1 must be seen by all other processors
before processor 1 checks for pending events in step 2 (that were recorded by
step A) and step A by processor 2 must be seen by all other processors
(checked in step 2) before step B is done.
The race I believed I was seeing is that steps 1 and 2 were
effectively swapped due to the __list_add() being delayed by the L2
cache not shared by some of the other processors. Imagine:
proc 2: just before step A
proc 1, step 1: adds to ctx->wait, but is not visible by other processors yet
proc 1, step 2: checks tail and sees no pending events
proc 2, step A: updates tail
proc 1, step 3: calls [io_]schedule() and sleeps
proc 2, step B: checks ctx->wait, but sees no one waiting, skips wakeup
so proc 1 sleeps indefinitely
My patch adds a memory barrier between steps A and B. It ensures that the
update in step 1 gets seen on processor 2 before continuing. If processor 1
was just before step 1, the memory barrier makes sure that step A (update
tail) gets seen by the time processor 1 makes it to step 2 (check tail).
Before the patch our AIO process would hang virtually 100% of the time. After
the patch, we have yet to see the process ever hang.
Signed-off-by: Quentin Barnes <qbarnes+linux@yahoo-inc.com>
Reviewed-by: Zach Brown <zach.brown@oracle.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: <stable@kernel.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ We should probably disallow that "if (waitqueue_active()) wake_up()"
coding pattern, because it's so often buggy wrt memory ordering ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-20 07:00:39 +07:00
|
|
|
/*
|
|
|
|
* We have to order our ring_info tail store above and test
|
|
|
|
* of the wait list below outside the wait lock. This is
|
|
|
|
* like in wake_up_bit() where clearing a bit has to be
|
|
|
|
* ordered with the unlocked test.
|
|
|
|
*/
|
|
|
|
smp_mb();
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
if (waitqueue_active(&ctx->wait))
|
|
|
|
wake_up(&ctx->wait);
|
|
|
|
|
2013-10-11 09:31:47 +07:00
|
|
|
percpu_ref_put(&ctx->reqs);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2009-09-23 06:43:53 +07:00
|
|
|
EXPORT_SYMBOL(aio_complete);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
/* aio_read_events
|
|
|
|
* Pull an event off of the ioctx's event ring. Returns the number of
|
|
|
|
* events fetched
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2013-05-08 06:18:45 +07:00
|
|
|
static long aio_read_events_ring(struct kioctx *ctx,
|
|
|
|
struct io_event __user *event, long nr)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct aio_ring *ring;
|
2013-05-10 05:36:07 +07:00
|
|
|
unsigned head, tail, pos;
|
2013-05-08 06:18:45 +07:00
|
|
|
long ret = 0;
|
|
|
|
int copy_ret;
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
mutex_lock(&ctx->ring_lock);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 21:14:45 +07:00
|
|
|
/* Access to ->ring_pages here is protected by ctx->ring_lock. */
|
2013-05-08 06:18:55 +07:00
|
|
|
ring = kmap_atomic(ctx->ring_pages[0]);
|
2013-05-08 06:18:45 +07:00
|
|
|
head = ring->head;
|
2013-05-10 05:36:07 +07:00
|
|
|
tail = ring->tail;
|
2013-05-08 06:18:45 +07:00
|
|
|
kunmap_atomic(ring);
|
|
|
|
|
2013-05-10 05:36:07 +07:00
|
|
|
pr_debug("h%u t%u m%u\n", head, tail, ctx->nr_events);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-10 05:36:07 +07:00
|
|
|
if (head == tail)
|
2005-04-17 05:20:36 +07:00
|
|
|
goto out;
|
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
while (ret < nr) {
|
|
|
|
long avail;
|
|
|
|
struct io_event *ev;
|
|
|
|
struct page *page;
|
|
|
|
|
2013-05-10 05:36:07 +07:00
|
|
|
avail = (head <= tail ? tail : ctx->nr_events) - head;
|
|
|
|
if (head == tail)
|
2013-05-08 06:18:45 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
avail = min(avail, nr - ret);
|
|
|
|
avail = min_t(long, avail, AIO_EVENTS_PER_PAGE -
|
|
|
|
((head + AIO_EVENTS_OFFSET) % AIO_EVENTS_PER_PAGE));
|
|
|
|
|
|
|
|
pos = head + AIO_EVENTS_OFFSET;
|
2013-05-08 06:18:55 +07:00
|
|
|
page = ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE];
|
2013-05-08 06:18:45 +07:00
|
|
|
pos %= AIO_EVENTS_PER_PAGE;
|
|
|
|
|
|
|
|
ev = kmap(page);
|
|
|
|
copy_ret = copy_to_user(event + ret, ev + pos,
|
|
|
|
sizeof(*ev) * avail);
|
|
|
|
kunmap(page);
|
|
|
|
|
|
|
|
if (unlikely(copy_ret)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret += avail;
|
|
|
|
head += avail;
|
2013-05-08 06:18:55 +07:00
|
|
|
head %= ctx->nr_events;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:55 +07:00
|
|
|
ring = kmap_atomic(ctx->ring_pages[0]);
|
2013-05-08 06:18:45 +07:00
|
|
|
ring->head = head;
|
2013-04-26 10:03:53 +07:00
|
|
|
kunmap_atomic(ring);
|
2013-05-08 06:18:55 +07:00
|
|
|
flush_dcache_page(ctx->ring_pages[0]);
|
2013-05-08 06:18:45 +07:00
|
|
|
|
2013-05-10 05:36:07 +07:00
|
|
|
pr_debug("%li h%u t%u\n", ret, head, tail);
|
2013-05-08 06:18:51 +07:00
|
|
|
|
2013-04-26 07:58:39 +07:00
|
|
|
put_reqs_available(ctx, ret);
|
2013-05-08 06:18:45 +07:00
|
|
|
out:
|
2013-05-08 06:18:55 +07:00
|
|
|
mutex_unlock(&ctx->ring_lock);
|
2013-05-08 06:18:45 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
static bool aio_read_events(struct kioctx *ctx, long min_nr, long nr,
|
|
|
|
struct io_event __user *event, long *i)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2013-05-08 06:18:45 +07:00
|
|
|
long ret = aio_read_events_ring(ctx, event + *i, nr - *i);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
if (ret > 0)
|
|
|
|
*i += ret;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
if (unlikely(atomic_read(&ctx->dead)))
|
|
|
|
ret = -EINVAL;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
if (!*i)
|
|
|
|
*i = ret;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
return ret < 0 || *i >= min_nr;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
static long read_events(struct kioctx *ctx, long min_nr, long nr,
|
2005-04-17 05:20:36 +07:00
|
|
|
struct io_event __user *event,
|
|
|
|
struct timespec __user *timeout)
|
|
|
|
{
|
2013-05-08 06:18:45 +07:00
|
|
|
ktime_t until = { .tv64 = KTIME_MAX };
|
|
|
|
long ret = 0;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
if (timeout) {
|
|
|
|
struct timespec ts;
|
2013-05-08 06:18:45 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
if (unlikely(copy_from_user(&ts, timeout, sizeof(ts))))
|
2013-05-08 06:18:45 +07:00
|
|
|
return -EFAULT;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
until = timespec_to_ktime(ts);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
/*
|
|
|
|
* Note that aio_read_events() is being called as the conditional - i.e.
|
|
|
|
* we're calling it after prepare_to_wait() has set task state to
|
|
|
|
* TASK_INTERRUPTIBLE.
|
|
|
|
*
|
|
|
|
* But aio_read_events() can block, and if it blocks it's going to flip
|
|
|
|
* the task state back to TASK_RUNNING.
|
|
|
|
*
|
|
|
|
* This should be ok, provided it doesn't flip the state back to
|
|
|
|
* TASK_RUNNING and return 0 too much - that causes us to spin. That
|
|
|
|
* will only happen if the mutex_lock() call blocks, and we then find
|
|
|
|
* the ringbuffer empty. So in practice we should be ok, but it's
|
|
|
|
* something to be aware of when touching this code.
|
|
|
|
*/
|
|
|
|
wait_event_interruptible_hrtimeout(ctx->wait,
|
|
|
|
aio_read_events(ctx, min_nr, nr, event, &ret), until);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
if (!ret && signal_pending(current))
|
|
|
|
ret = -EINTR;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:18:45 +07:00
|
|
|
return ret;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* sys_io_setup:
|
|
|
|
* Create an aio_context capable of receiving at least nr_events.
|
|
|
|
* ctxp must not point to an aio_context that already exists, and
|
|
|
|
* must be initialized to 0 prior to the call. On successful
|
|
|
|
* creation of the aio_context, *ctxp is filled in with the resulting
|
|
|
|
* handle. May fail with -EINVAL if *ctxp is not initialized,
|
|
|
|
* if the specified nr_events exceeds internal limits. May fail
|
|
|
|
* with -EAGAIN if the specified nr_events exceeds the user's limit
|
|
|
|
* of available events. May fail with -ENOMEM if insufficient kernel
|
|
|
|
* resources are available. May fail with -EFAULT if an invalid
|
|
|
|
* pointer is passed for ctxp. Will fail with -ENOSYS if not
|
|
|
|
* implemented.
|
|
|
|
*/
|
2009-01-14 20:14:18 +07:00
|
|
|
SYSCALL_DEFINE2(io_setup, unsigned, nr_events, aio_context_t __user *, ctxp)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kioctx *ioctx = NULL;
|
|
|
|
unsigned long ctx;
|
|
|
|
long ret;
|
|
|
|
|
|
|
|
ret = get_user(ctx, ctxp);
|
|
|
|
if (unlikely(ret))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ret = -EINVAL;
|
2005-11-07 15:59:31 +07:00
|
|
|
if (unlikely(ctx || nr_events == 0)) {
|
|
|
|
pr_debug("EINVAL: io_setup: ctx %lu nr_events %u\n",
|
|
|
|
ctx, nr_events);
|
2005-04-17 05:20:36 +07:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ioctx = ioctx_alloc(nr_events);
|
|
|
|
ret = PTR_ERR(ioctx);
|
|
|
|
if (!IS_ERR(ioctx)) {
|
|
|
|
ret = put_user(ioctx->user_id, ctxp);
|
2012-03-21 03:27:57 +07:00
|
|
|
if (ret)
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
kill_ioctx(current->mm, ioctx);
|
2013-05-29 05:14:48 +07:00
|
|
|
percpu_ref_put(&ioctx->users);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* sys_io_destroy:
|
|
|
|
* Destroy the aio_context specified. May cancel any outstanding
|
|
|
|
* AIOs and block on completion. Will fail with -ENOSYS if not
|
2010-08-06 01:23:11 +07:00
|
|
|
* implemented. May fail with -EINVAL if the context pointed to
|
2005-04-17 05:20:36 +07:00
|
|
|
* is invalid.
|
|
|
|
*/
|
2009-01-14 20:14:18 +07:00
|
|
|
SYSCALL_DEFINE1(io_destroy, aio_context_t, ctx)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kioctx *ioctx = lookup_ioctx(ctx);
|
|
|
|
if (likely(NULL != ioctx)) {
|
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 23:54:40 +07:00
|
|
|
kill_ioctx(current->mm, ioctx);
|
2013-05-29 05:14:48 +07:00
|
|
|
percpu_ref_put(&ioctx->users);
|
2005-04-17 05:20:36 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
pr_debug("EINVAL: io_destroy: invalid context id\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-05-08 06:19:11 +07:00
|
|
|
typedef ssize_t (aio_rw_op)(struct kiocb *, const struct iovec *,
|
|
|
|
unsigned long, loff_t);
|
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
static ssize_t aio_setup_vectored_rw(struct kiocb *kiocb,
|
|
|
|
int rw, char __user *buf,
|
|
|
|
unsigned long *nr_segs,
|
|
|
|
struct iovec **iovec,
|
|
|
|
bool compat)
|
2006-10-01 13:28:49 +07:00
|
|
|
{
|
|
|
|
ssize_t ret;
|
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
*nr_segs = kiocb->ki_nbytes;
|
2013-05-08 06:19:11 +07:00
|
|
|
|
2010-05-27 04:44:26 +07:00
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
if (compat)
|
2013-05-08 06:19:11 +07:00
|
|
|
ret = compat_rw_copy_check_uvector(rw,
|
2013-02-26 07:36:27 +07:00
|
|
|
(struct compat_iovec __user *)buf,
|
|
|
|
*nr_segs, 1, *iovec, iovec);
|
2010-05-27 04:44:26 +07:00
|
|
|
else
|
|
|
|
#endif
|
2013-05-08 06:19:11 +07:00
|
|
|
ret = rw_copy_check_uvector(rw,
|
2013-02-26 07:36:27 +07:00
|
|
|
(struct iovec __user *)buf,
|
|
|
|
*nr_segs, 1, *iovec, iovec);
|
2006-10-01 13:28:49 +07:00
|
|
|
if (ret < 0)
|
2013-05-08 06:19:11 +07:00
|
|
|
return ret;
|
2012-05-22 06:06:20 +07:00
|
|
|
|
2013-05-08 06:19:11 +07:00
|
|
|
/* ki_nbytes now reflect bytes instead of segs */
|
2006-10-01 13:28:49 +07:00
|
|
|
kiocb->ki_nbytes = ret;
|
2013-05-08 06:19:11 +07:00
|
|
|
return 0;
|
2006-10-01 13:28:49 +07:00
|
|
|
}
|
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
static ssize_t aio_setup_single_vector(struct kiocb *kiocb,
|
|
|
|
int rw, char __user *buf,
|
|
|
|
unsigned long *nr_segs,
|
|
|
|
struct iovec *iovec)
|
2006-10-01 13:28:49 +07:00
|
|
|
{
|
2013-02-26 07:36:27 +07:00
|
|
|
if (unlikely(!access_ok(!rw, buf, kiocb->ki_nbytes)))
|
2013-05-08 06:19:11 +07:00
|
|
|
return -EFAULT;
|
2012-05-22 06:06:20 +07:00
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
iovec->iov_base = buf;
|
|
|
|
iovec->iov_len = kiocb->ki_nbytes;
|
|
|
|
*nr_segs = 1;
|
2006-10-01 13:28:49 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* aio_setup_iocb:
|
|
|
|
* Performs the initial checks and aio retry method
|
|
|
|
* setup for the kiocb at the time of io submission.
|
|
|
|
*/
|
2013-02-26 07:36:27 +07:00
|
|
|
static ssize_t aio_run_iocb(struct kiocb *req, unsigned opcode,
|
|
|
|
char __user *buf, bool compat)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2013-05-08 06:19:11 +07:00
|
|
|
struct file *file = req->ki_filp;
|
|
|
|
ssize_t ret;
|
2013-02-26 07:36:27 +07:00
|
|
|
unsigned long nr_segs;
|
2013-05-08 06:19:11 +07:00
|
|
|
int rw;
|
|
|
|
fmode_t mode;
|
|
|
|
aio_rw_op *rw_op;
|
2013-02-26 07:36:27 +07:00
|
|
|
struct iovec inline_vec, *iovec = &inline_vec;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
switch (opcode) {
|
2005-04-17 05:20:36 +07:00
|
|
|
case IOCB_CMD_PREAD:
|
2006-10-01 13:28:49 +07:00
|
|
|
case IOCB_CMD_PREADV:
|
2013-05-08 06:19:11 +07:00
|
|
|
mode = FMODE_READ;
|
|
|
|
rw = READ;
|
|
|
|
rw_op = file->f_op->aio_read;
|
|
|
|
goto rw_common;
|
|
|
|
|
|
|
|
case IOCB_CMD_PWRITE:
|
2006-10-01 13:28:49 +07:00
|
|
|
case IOCB_CMD_PWRITEV:
|
2013-05-08 06:19:11 +07:00
|
|
|
mode = FMODE_WRITE;
|
|
|
|
rw = WRITE;
|
|
|
|
rw_op = file->f_op->aio_write;
|
|
|
|
goto rw_common;
|
|
|
|
rw_common:
|
|
|
|
if (unlikely(!(file->f_mode & mode)))
|
|
|
|
return -EBADF;
|
|
|
|
|
|
|
|
if (!rw_op)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
ret = (opcode == IOCB_CMD_PREADV ||
|
|
|
|
opcode == IOCB_CMD_PWRITEV)
|
|
|
|
? aio_setup_vectored_rw(req, rw, buf, &nr_segs,
|
|
|
|
&iovec, compat)
|
|
|
|
: aio_setup_single_vector(req, rw, buf, &nr_segs,
|
|
|
|
iovec);
|
2006-10-01 13:28:49 +07:00
|
|
|
if (ret)
|
2013-05-08 06:19:11 +07:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = rw_verify_area(rw, file, &req->ki_pos, req->ki_nbytes);
|
2013-02-26 07:36:27 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
if (iovec != &inline_vec)
|
|
|
|
kfree(iovec);
|
2013-05-08 06:19:11 +07:00
|
|
|
return ret;
|
2013-02-26 07:36:27 +07:00
|
|
|
}
|
2013-05-08 06:19:11 +07:00
|
|
|
|
|
|
|
req->ki_nbytes = ret;
|
|
|
|
|
2013-05-10 05:03:42 +07:00
|
|
|
/* XXX: move/kill - rw_verify_area()? */
|
|
|
|
/* This matches the pread()/pwrite() logic */
|
|
|
|
if (req->ki_pos < 0) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rw == WRITE)
|
|
|
|
file_start_write(file);
|
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
ret = rw_op(req, iovec, nr_segs, req->ki_pos);
|
2013-05-10 05:03:42 +07:00
|
|
|
|
|
|
|
if (rw == WRITE)
|
|
|
|
file_end_write(file);
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
2013-05-08 06:19:11 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
case IOCB_CMD_FDSYNC:
|
2013-05-08 06:19:11 +07:00
|
|
|
if (!file->f_op->aio_fsync)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ret = file->f_op->aio_fsync(req, 1);
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
2013-05-08 06:19:11 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
case IOCB_CMD_FSYNC:
|
2013-05-08 06:19:11 +07:00
|
|
|
if (!file->f_op->aio_fsync)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ret = file->f_op->aio_fsync(req, 0);
|
2005-04-17 05:20:36 +07:00
|
|
|
break;
|
2013-05-08 06:19:11 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
default:
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("EINVAL: no operation provided\n");
|
2013-05-08 06:19:11 +07:00
|
|
|
return -EINVAL;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
if (iovec != &inline_vec)
|
|
|
|
kfree(iovec);
|
|
|
|
|
2013-05-08 06:19:11 +07:00
|
|
|
if (ret != -EIOCBQUEUED) {
|
|
|
|
/*
|
|
|
|
* There's no easy way to restart the syscall since other AIO's
|
|
|
|
* may be already running. Just fail this IO with EINTR.
|
|
|
|
*/
|
|
|
|
if (unlikely(ret == -ERESTARTSYS || ret == -ERESTARTNOINTR ||
|
|
|
|
ret == -ERESTARTNOHAND ||
|
|
|
|
ret == -ERESTART_RESTARTBLOCK))
|
|
|
|
ret = -EINTR;
|
|
|
|
aio_complete(req, ret, 0);
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-29 14:58:57 +07:00
|
|
|
static int io_submit_one(struct kioctx *ctx, struct iocb __user *user_iocb,
|
2013-05-08 06:18:53 +07:00
|
|
|
struct iocb *iocb, bool compat)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kiocb *req;
|
|
|
|
ssize_t ret;
|
|
|
|
|
|
|
|
/* enforce forwards compatibility on users */
|
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:23:21 +07:00
|
|
|
if (unlikely(iocb->aio_reserved1 || iocb->aio_reserved2)) {
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("EINVAL: reserve field set\n");
|
2005-04-17 05:20:36 +07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* prevent overflows */
|
|
|
|
if (unlikely(
|
|
|
|
(iocb->aio_buf != (unsigned long)iocb->aio_buf) ||
|
|
|
|
(iocb->aio_nbytes != (size_t)iocb->aio_nbytes) ||
|
|
|
|
((ssize_t)iocb->aio_nbytes < 0)
|
|
|
|
)) {
|
|
|
|
pr_debug("EINVAL: io_submit: overflow check\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-05-08 06:19:11 +07:00
|
|
|
req = aio_get_req(ctx);
|
2013-05-08 06:18:37 +07:00
|
|
|
if (unlikely(!req))
|
2005-04-17 05:20:36 +07:00
|
|
|
return -EAGAIN;
|
2013-05-08 06:18:37 +07:00
|
|
|
|
|
|
|
req->ki_filp = fget(iocb->aio_fildes);
|
|
|
|
if (unlikely(!req->ki_filp)) {
|
|
|
|
ret = -EBADF;
|
|
|
|
goto out_put_req;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2013-05-08 06:18:37 +07:00
|
|
|
|
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:23:21 +07:00
|
|
|
if (iocb->aio_flags & IOCB_FLAG_RESFD) {
|
|
|
|
/*
|
|
|
|
* If the IOCB_FLAG_RESFD flag of aio_flags is set, get an
|
|
|
|
* instance of the file* now. The file descriptor must be
|
|
|
|
* an eventfd() fd, and will be signaled for each completed
|
|
|
|
* event using the eventfd_signal() function.
|
|
|
|
*/
|
2009-07-01 01:41:11 +07:00
|
|
|
req->ki_eventfd = eventfd_ctx_fdget((int) iocb->aio_resfd);
|
2008-04-29 15:03:09 +07:00
|
|
|
if (IS_ERR(req->ki_eventfd)) {
|
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:23:21 +07:00
|
|
|
ret = PTR_ERR(req->ki_eventfd);
|
2009-03-19 07:04:19 +07:00
|
|
|
req->ki_eventfd = NULL;
|
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 12:23:21 +07:00
|
|
|
goto out_put_req;
|
|
|
|
}
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-08 06:19:10 +07:00
|
|
|
ret = put_user(KIOCB_KEY, &user_iocb->aio_key);
|
2005-04-17 05:20:36 +07:00
|
|
|
if (unlikely(ret)) {
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("EFAULT: aio_key\n");
|
2005-04-17 05:20:36 +07:00
|
|
|
goto out_put_req;
|
|
|
|
}
|
|
|
|
|
|
|
|
req->ki_obj.user = user_iocb;
|
|
|
|
req->ki_user_data = iocb->aio_data;
|
|
|
|
req->ki_pos = iocb->aio_offset;
|
2013-05-10 05:03:42 +07:00
|
|
|
req->ki_nbytes = iocb->aio_nbytes;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-02-26 07:36:27 +07:00
|
|
|
ret = aio_run_iocb(req, iocb->aio_lio_opcode,
|
|
|
|
(char __user *)(unsigned long)iocb->aio_buf,
|
|
|
|
compat);
|
2013-05-08 06:18:25 +07:00
|
|
|
if (ret)
|
2011-02-26 05:44:27 +07:00
|
|
|
goto out_put_req;
|
2013-05-08 06:18:25 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
return 0;
|
|
|
|
out_put_req:
|
2013-04-26 07:58:39 +07:00
|
|
|
put_reqs_available(ctx, 1);
|
2013-10-11 09:31:47 +07:00
|
|
|
percpu_ref_put(&ctx->reqs);
|
2013-05-14 03:42:52 +07:00
|
|
|
kiocb_free(req);
|
2005-04-17 05:20:36 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-05-27 04:44:26 +07:00
|
|
|
long do_io_submit(aio_context_t ctx_id, long nr,
|
|
|
|
struct iocb __user *__user *iocbpp, bool compat)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kioctx *ctx;
|
|
|
|
long ret = 0;
|
2011-11-03 03:40:10 +07:00
|
|
|
int i = 0;
|
2010-07-01 12:55:01 +07:00
|
|
|
struct blk_plug plug;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
if (unlikely(nr < 0))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2010-09-11 04:16:00 +07:00
|
|
|
if (unlikely(nr > LONG_MAX/sizeof(*iocbpp)))
|
|
|
|
nr = LONG_MAX/sizeof(*iocbpp);
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)))))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
ctx = lookup_ioctx(ctx_id);
|
|
|
|
if (unlikely(!ctx)) {
|
2013-05-08 06:18:35 +07:00
|
|
|
pr_debug("EINVAL: invalid context id\n");
|
2005-04-17 05:20:36 +07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2010-07-01 12:55:01 +07:00
|
|
|
blk_start_plug(&plug);
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* AKPM: should this return a partial result if some of the IOs were
|
|
|
|
* successfully submitted?
|
|
|
|
*/
|
|
|
|
for (i=0; i<nr; i++) {
|
|
|
|
struct iocb __user *user_iocb;
|
|
|
|
struct iocb tmp;
|
|
|
|
|
|
|
|
if (unlikely(__get_user(user_iocb, iocbpp + i))) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(copy_from_user(&tmp, user_iocb, sizeof(tmp)))) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-05-08 06:18:53 +07:00
|
|
|
ret = io_submit_one(ctx, user_iocb, &tmp, compat);
|
2005-04-17 05:20:36 +07:00
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
2010-07-01 12:55:01 +07:00
|
|
|
blk_finish_plug(&plug);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-29 05:14:48 +07:00
|
|
|
percpu_ref_put(&ctx->users);
|
2005-04-17 05:20:36 +07:00
|
|
|
return i ? i : ret;
|
|
|
|
}
|
|
|
|
|
2010-05-27 04:44:26 +07:00
|
|
|
/* sys_io_submit:
|
|
|
|
* Queue the nr iocbs pointed to by iocbpp for processing. Returns
|
|
|
|
* the number of iocbs queued. May return -EINVAL if the aio_context
|
|
|
|
* specified by ctx_id is invalid, if nr is < 0, if the iocb at
|
|
|
|
* *iocbpp[0] is not properly initialized, if the operation specified
|
|
|
|
* is invalid for the file descriptor in the iocb. May fail with
|
|
|
|
* -EFAULT if any of the data structures point to invalid data. May
|
|
|
|
* fail with -EBADF if the file descriptor specified in the first
|
|
|
|
* iocb is invalid. May fail with -EAGAIN if insufficient resources
|
|
|
|
* are available to queue any iocbs. Will return 0 if nr is 0. Will
|
|
|
|
* fail with -ENOSYS if not implemented.
|
|
|
|
*/
|
|
|
|
SYSCALL_DEFINE3(io_submit, aio_context_t, ctx_id, long, nr,
|
|
|
|
struct iocb __user * __user *, iocbpp)
|
|
|
|
{
|
|
|
|
return do_io_submit(ctx_id, nr, iocbpp, 0);
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* lookup_kiocb
|
|
|
|
* Finds a given iocb for cancellation.
|
|
|
|
*/
|
2005-04-25 22:18:14 +07:00
|
|
|
static struct kiocb *lookup_kiocb(struct kioctx *ctx, struct iocb __user *iocb,
|
|
|
|
u32 key)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct list_head *pos;
|
2005-11-14 07:07:34 +07:00
|
|
|
|
|
|
|
assert_spin_locked(&ctx->ctx_lock);
|
|
|
|
|
2013-05-08 06:19:10 +07:00
|
|
|
if (key != KIOCB_KEY)
|
|
|
|
return NULL;
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/* TODO: use a hash or array, this sucks. */
|
|
|
|
list_for_each(pos, &ctx->active_reqs) {
|
|
|
|
struct kiocb *kiocb = list_kiocb(pos);
|
2013-05-08 06:19:10 +07:00
|
|
|
if (kiocb->ki_obj.user == iocb)
|
2005-04-17 05:20:36 +07:00
|
|
|
return kiocb;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* sys_io_cancel:
|
|
|
|
* Attempts to cancel an iocb previously passed to io_submit. If
|
|
|
|
* the operation is successfully cancelled, the resulting event is
|
|
|
|
* copied into the memory pointed to by result without being placed
|
|
|
|
* into the completion queue and 0 is returned. May fail with
|
|
|
|
* -EFAULT if any of the data structures pointed to are invalid.
|
|
|
|
* May fail with -EINVAL if aio_context specified by ctx_id is
|
|
|
|
* invalid. May fail with -EAGAIN if the iocb specified was not
|
|
|
|
* cancelled. Will fail with -ENOSYS if not implemented.
|
|
|
|
*/
|
2009-01-14 20:14:18 +07:00
|
|
|
SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct iocb __user *, iocb,
|
|
|
|
struct io_event __user *, result)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kioctx *ctx;
|
|
|
|
struct kiocb *kiocb;
|
|
|
|
u32 key;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = get_user(key, &iocb->aio_key);
|
|
|
|
if (unlikely(ret))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
ctx = lookup_ioctx(ctx_id);
|
|
|
|
if (unlikely(!ctx))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
spin_lock_irq(&ctx->ctx_lock);
|
2013-05-08 06:18:31 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
kiocb = lookup_kiocb(ctx, iocb, key);
|
2013-05-08 06:18:31 +07:00
|
|
|
if (kiocb)
|
2013-05-14 04:45:08 +07:00
|
|
|
ret = kiocb_cancel(ctx, kiocb);
|
2013-05-08 06:18:31 +07:00
|
|
|
else
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
spin_unlock_irq(&ctx->ctx_lock);
|
|
|
|
|
2013-05-08 06:18:31 +07:00
|
|
|
if (!ret) {
|
2013-05-14 04:45:08 +07:00
|
|
|
/*
|
|
|
|
* The result argument is no longer used - the io_event is
|
|
|
|
* always delivered via the ring buffer. -EINPROGRESS indicates
|
|
|
|
* cancellation is progress:
|
2013-05-08 06:18:31 +07:00
|
|
|
*/
|
2013-05-14 04:45:08 +07:00
|
|
|
ret = -EINPROGRESS;
|
2013-05-08 06:18:31 +07:00
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-05-29 05:14:48 +07:00
|
|
|
percpu_ref_put(&ctx->users);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* io_getevents:
|
|
|
|
* Attempts to read at least min_nr events and up to nr events from
|
2010-08-06 01:23:11 +07:00
|
|
|
* the completion queue for the aio_context specified by ctx_id. If
|
|
|
|
* it succeeds, the number of read events is returned. May fail with
|
|
|
|
* -EINVAL if ctx_id is invalid, if min_nr is out of range, if nr is
|
|
|
|
* out of range, if timeout is out of range. May fail with -EFAULT
|
|
|
|
* if any of the memory specified is invalid. May return 0 or
|
|
|
|
* < min_nr if the timeout specified by timeout has elapsed
|
|
|
|
* before sufficient events are available, where timeout == NULL
|
|
|
|
* specifies an infinite timeout. Note that the timeout pointed to by
|
2013-05-25 05:55:24 +07:00
|
|
|
* timeout is relative. Will fail with -ENOSYS if not implemented.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2009-01-14 20:14:18 +07:00
|
|
|
SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
|
|
|
|
long, min_nr,
|
|
|
|
long, nr,
|
|
|
|
struct io_event __user *, events,
|
|
|
|
struct timespec __user *, timeout)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct kioctx *ioctx = lookup_ioctx(ctx_id);
|
|
|
|
long ret = -EINVAL;
|
|
|
|
|
|
|
|
if (likely(ioctx)) {
|
2011-01-13 08:01:08 +07:00
|
|
|
if (likely(min_nr <= nr && min_nr >= 0))
|
2005-04-17 05:20:36 +07:00
|
|
|
ret = read_events(ioctx, min_nr, nr, events, timeout);
|
2013-05-29 05:14:48 +07:00
|
|
|
percpu_ref_put(&ioctx->users);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|