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

2010-09-02 Thread Miao Xie
On Thu, 02 Sep 2010 15:55:44 +1000, Chris Samuel wrote: 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 ? I just change the 2.1 to

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

2010-09-02 Thread Ingo Molnar
* Miao Xie mi...@cn.fujitsu.com wrote: - change the version of GPL from version 2.1 to version 2 How were you able to do this? If the code derives from glibc (as your comments in the patches suggest), and if glibc is under the GPL v2.1, then you probably cannot simply change the license to

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

2010-09-02 Thread Chris Samuel
On 02/09/10 16:50, Miao Xie wrote: I just change the 2.1 to 2 in your patch, because the orignal code is LGPL v2.1, LGPL v2.1 permits us to apply the terms of the ordinary GNU General Public License instead of it. Ahhh excellent, I hadn't realised that was possible; well spotted! cheers,

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

2010-09-02 Thread Chris Samuel
On 02/09/10 16:53, Ingo Molnar wrote: and if glibc is under the GPL v2.1 It's LGPL v2.1 which can be converted to GPL v2 under section 3 of its license. See: http://www.gnu.org/licenses/lgpl-2.1.html cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To

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

2010-09-02 Thread Miao Xie
On Thu, 2 Sep 2010 08:53:47 +0200, Ingo Molnar wrote: * Miao Xiemi...@cn.fujitsu.com wrote: - change the version of GPL from version 2.1 to version 2 How were you able to do this? If the code derives from glibc (as your comments in the patches suggest), and if glibc is under the GPL v2.1,

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

2010-09-02 Thread Peter Zijlstra
On Thu, 2010-09-02 at 13:44 +0800, Miao Xie wrote: 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

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

2010-09-02 Thread Peter Zijlstra
On Thu, 2010-09-02 at 09:55 +0200, Peter Zijlstra wrote: On Thu, 2010-09-02 at 13:44 +0800, Miao Xie wrote: 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

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

2010-09-02 Thread Jiri Slaby
On 09/02/2010 03:02 AM, David Rientjes wrote: --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -334,6 +334,57 @@ static inline void *kzalloc_node(size_t size, gfp_t flags, int node) return kmalloc_node(size, flags | __GFP_ZERO, node); } +/** + * kmalloc_nofail -

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

2010-09-02 Thread chxand...@gmail.com
On 2 September 2010 14:07, Chris Samuel ch...@csamuel.org wrote: On 02/09/10 16:50, Miao Xie wrote: I just change the 2.1 to 2 in your patch, because the orignal code is LGPL v2.1, LGPL v2.1 permits us to apply the terms of the ordinary GNU General Public License instead of it. Ahhh

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

2010-09-02 Thread Chris Samuel
On 02/09/10 18:16, chxand...@gmail.com wrote: Umm, isn't the only one that can do that the copyright holder? The copyright holder can use whatever license they wish; the LGPL tells the licensee what rights *they* have, which includes distributing the software under the (more strict) GPLv2.

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

2010-09-02 Thread chxand...@gmail.com
On 2 September 2010 15:24, Chris Samuel ch...@csamuel.org wrote: On 02/09/10 18:16, chxand...@gmail.com wrote: Umm, isn't the only one that can do that the copyright holder? The copyright holder can use whatever license they wish; the LGPL tells the licensee what rights *they* have, which

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

2010-09-02 Thread Andi Kleen
Miao Xie mi...@cn.fujitsu.com writes: 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 Can you

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

2010-09-02 Thread Miao Xie
On Thu, 02 Sep 2010 10:55:58 +0200, Andi Kleen wrote: Miao Xiemi...@cn.fujitsu.com writes: 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

Re: BTRFS: Unbelievably slow with kvm/qemu

2010-09-02 Thread Ted Ts'o
On Tue, Aug 31, 2010 at 02:58:44PM -0700, K. Richard Pixley wrote: On 20100831 14:46, Mike Fedyk wrote: There is little reason not to use duplicate metadata. Only small files (less than 2kb) get stored in the tree, so there should be no worries about images being duplicated without data

mount a compressed btrfs without compress cause kernel oops

2010-09-02 Thread Grissiom
Hello devs, I'm a slackware user that tried btrfs recently. My kernel version is 2.6.35.4, btrfs-progs is on the date of 20100902. I have sdb7 in btrfs. I mounted with compress feature in the past, and had put some files(~8GB) in it. However, I mount it without compress feature today. When I

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

2010-09-02 Thread Jan Kara
On Thu 02-09-10 09:59:13, Jiri Slaby wrote: On 09/02/2010 03:02 AM, David Rientjes wrote: --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -334,6 +334,57 @@ static inline void *kzalloc_node(size_t size, gfp_t flags, int node) return kmalloc_node(size, flags | __GFP_ZERO, node); }

Re: BTRFS: Unbelievably slow with kvm/qemu

2010-09-02 Thread K. Richard Pixley
On 9/1/10 17:18 , Ted Ts'o wrote: On Tue, Aug 31, 2010 at 02:58:44PM -0700, K. Richard Pixley wrote: On 20100831 14:46, Mike Fedyk wrote: There is little reason not to use duplicate metadata. Only small files (less than 2kb) get stored in the tree, so there should be no worries about

Re: BTRFS: Unbelievably slow with kvm/qemu

2010-09-02 Thread K. Richard Pixley
On 9/2/10 09:36 , K. Richard Pixley wrote: On 9/1/10 17:18 , Ted Ts'o wrote: On Tue, Aug 31, 2010 at 02:58:44PM -0700, K. Richard Pixley wrote: On 20100831 14:46, Mike Fedyk wrote: There is little reason not to use duplicate metadata. Only small files (less than 2kb) get stored in the

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

2010-09-02 Thread Neil Brown
On Thu, 2 Sep 2010 16:51:41 +0200 Jan Kara j...@suse.cz wrote: On Thu 02-09-10 09:59:13, Jiri Slaby wrote: On 09/02/2010 03:02 AM, David Rientjes wrote: --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -334,6 +334,57 @@ static inline void *kzalloc_node(size_t size, gfp_t flags,

[PATCH 2/2] btrfs: better error handling in xattr.c

2010-09-02 Thread Mark Fasheh
This was quite trivial - there's only 3 places I counted where we weren't handling errors. None of the sites looked like they needed any additional unrolling either. Signed-off-by: Mark Fasheh mfas...@suse.com --- fs/btrfs/xattr.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-)