Re: Question about specific patch (eMMC)

2010-09-01 Thread Alexander Vdovichev
Hi, On Tue, 2010-08-31 at 19:27 +0200, ext Tomasz Torcz wrote: On Tue, Aug 31, 2010 at 02:57:05PM +0300, Alexander Vdovichev wrote: Hello all, Is there any patches for btrfs to use enhanced area in eMMC (it will allow to boost performance i.e. it very useful to keep metadata within this

[PATCH 0/3] improve the performance of some memory copy functions

2010-09-01 Thread Miao Xie
When I looked into the performance problem of the btrfs, I found some memory copy functions of the kernel(such as: x86_64's memmove)is very inefficient, but the glibc version is quite fast, in some cases it is 10 times faster than the kernel version. This patchset introduced some macros and

[PATCH 1/3] lib: introduce some memory copy macros and functions

2010-09-01 Thread Miao Xie
the kernel's memcpy and memmove is very inefficient. But the glibc version is quite fast, in some cases it is 10 times faster than the kernel version. So I introduce some memory copy macros and functions of the glibc to improve the kernel version's performance. The strategy of the memory

[PATCH 2/3] lib: improve the performance of memcpy and memmove of the general version

2010-09-01 Thread Miao Xie
the performance of memcpy and memmove of the general version is very inefficient, this patch improved them. Signed-off-by: Miao Xie mi...@cn.fujitsu.com --- lib/string.c | 32 ++-- 1 files changed, 14 insertions(+), 18 deletions(-) diff --git a/lib/string.c

[PATCH 3/3] x86_64/lib: improve the performance of memmove

2010-09-01 Thread Miao Xie
This patch improved the performance of memmove on x86_64 by using mem_copy_bwd() instead of byte copy. But x86_64's memcpy is quite fast, so I didn't change it. I have tested this patchset by doing 500 bytes memory copy for 5 times on my x86_64 box: memmove 2.6.36-rc1

Re: [PATCH 2/2] Btrfs-progs: Add hot data support in mkfs

2010-09-01 Thread Hubert Kario
On Friday 13 August 2010 16:10:24 Ben Chociej wrote: It's a good point, of course. Ideally we would be able to prioritize data and place them on 15k versus 7.2krpm disks, etc. However you get to a point where's there's only incremental benefit. For that reason, the scope of this project was

Re: [PATCH 1/3] lib: introduce some memory copy macros and functions

2010-09-01 Thread Peter Zijlstra
On Wed, 2010-09-01 at 18:36 +0800, Miao Xie wrote: + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2.1 of the License, or (at your option) + *

[patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc

2010-09-01 Thread David Rientjes
Add kmalloc_nofail(), kcalloc_nofail(), and kzalloc_nofail(). These functions are equivalent to kmalloc(), kcalloc(), and kzalloc(), respectively, except that they will never return NULL and instead loop forever trying to allocate memory. If the first allocation attempt fails because the page

[patch v2 4/5] btrfs: add nofail variant of set_extent_dirty

2010-09-01 Thread David Rientjes
Add set_extent_dirty_nofail(). This function is equivalent to set_extent_dirty(), except that it will never fail because of allocation failure and instead loop forever trying to allocate memory. If the first allocation attempt fails because the page allocator doesn't implicitly loop, a warning

Re: [PATCH 1/3] lib: introduce some memory copy macros and functions

2010-09-01 Thread Miao Xie
On Wed, 01 Sep 2010 17:25:36 +0200, Peter Zijlstra wrote: On Wed, 2010-09-01 at 18:36 +0800, Miao Xie wrote: + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either

[PATCH V2 0/3] improve the performance of some memory copy functions

2010-09-01 Thread Miao Xie
Changes from V1 to V2: - change the version of GPL from version 2.1 to version 2 When I looked into the performance problem of the btrfs, I found some memory copy functions of the kernel(such as: x86_64's memmove)is very inefficient, but the glibc version is quite fast, in some cases it is 10

[PATCH V2 1/3] lib: introduce some memory copy macros and functions

2010-09-01 Thread Miao Xie
Changes from V1 to V2: - change the version of GPL from version 2.1 to version 2 the kernel's memcpy and memmove is very inefficient. But the glibc version is quite fast, in some cases it is 10 times faster than the kernel version. So I introduce some memory copy macros and functions of the glibc

[PATCH 3/3] x86_64/lib: improve the performance of memmove

2010-09-01 Thread Miao Xie
This patch improved the performance of memmove on x86_64 by using mem_copy_bwd() instead of byte copy. But x86_64's memcpy is quite fast, so I didn't change it. I have tested this patchset by doing 500 bytes memory copy for 5 times on my x86_64 box: memmove 2.6.36-rc1

[PATCH 2/3] lib: improve the performance of memcpy and memmove of the general version

2010-09-01 Thread Miao Xie
the performance of memcpy and memmove of the general version is very inefficient, this patch improved them. Signed-off-by: Miao Xie mi...@cn.fujitsu.com --- lib/string.c | 32 ++-- 1 files changed, 14 insertions(+), 18 deletions(-) diff --git a/lib/string.c

Re: [PATCH 1/3] lib: introduce some memory copy macros and functions

2010-09-01 Thread Chris Samuel
Hiya, On 02/09/10 15:44, Miao Xie wrote: Ok, I will change it. Did you just change the 2.1 to 2 in your patch, or did you find a specifically version 2 licensed version of that code ? If so, where was that ? cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To