On Wed, 5 Sep 2012 18:16:19 +0200, David Sterba wrote:

On Wed, Aug 29, 2012 at 12:12:50PM +0800, Miao Xie wrote:

quoted

The ordered extent allocation is in the fast path of the IO, so use a slab
to improve the speed of the allocation.

Good. Size of the struct is 280, so this will fall into the size-512
bucket, giving 8 objects per page, while own slab will pack 14 objects
into a page.

Another benefit I see is to check for leaked objects when the
module is removed (and the cache destroy takes place).

quoted

Signed-off-by: Miao Xie <redacted>
---
 fs/btrfs/ordered-data.c |   23 +++++++++++++++++++++--
 fs/btrfs/ordered-data.h |    2 ++
 fs/btrfs/super.c        |    9 ++++++++-
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index 2eb79cc..a07ae77 100644
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c

@@ -958,3 +960,20 @@ void btrfs_add_ordered_operation(struct btrfs_trans_handle *trans,
 	}
 	spin_unlock(&root->fs_info->ordered_extent_lock);
 }
+
+int __init ordered_data_init(void)
+{
+	ordered_extent_cache = kmem_cache_create("ordered_extent",

Please use the 'btrfs_' prefix, ie. 'btrfs_ordered_extent'

Thanks for your review. I'll update this patch by your advice.

Regards
Miao

quoted

+				sizeof(struct btrfs_ordered_extent), 0,
+				SLAB_RECLAIM_ACCOUNT | SLAB_MEM_SPREAD,
+				NULL);
+	if (!ordered_extent_cache)
+		return -ENOMEM;
+	return 0;
+}
+