GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that multiple given
arrays are independent and then give the loop optimizer
more freedom to handle expressions in the loop that
accesses these arrays.
Since there are no loops in the list functions
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that multiple given
arrays are independent and then give the loop optimizer
more freedom to handle expressions in the loop that
accesses
On Wed, Jan 21, 2009 at 10:20:49AM +0100, Andi Kleen wrote:
On Wed, Jan 21, 2009 at 09:52:08AM +0100, Nick Piggin wrote:
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that
* Pavel Machek (pa...@suse.cz) wrote:
On Tue 2009-01-20 18:34:55, Eric Sesterhenn wrote:
* Dave Chinner (da...@fromorbit.com) wrote:
On Tue, Jan 20, 2009 at 11:15:03AM +0100, Eric Sesterhenn wrote:
* Dave Chinner (da...@fromorbit.com) wrote:
On Tue, Jan 20, 2009 at 07:31:50AM +0100,
The point is that the compiler is then free to do it. If things
slow down after the compiler gets *more* information, then that
is a problem with the compiler heuristics rather than the
information we give it.
The point was the -Os disables it typically then.
(not always, compiler heuristics
Hello,
replace_one_extent search tree leaves for references to
a given extent. It stop searching if goes beyond the last
possible position. The last possible position is computed
by adding the starting offset of a found file extent to
the full size of the extent. The code uses physical size
of
Hello,
btrfs_extent_post_op calls finish_current_insert and
del_pending_extents. They both may enter infinite loop.
finish_current_insert enters infinite loop if it only
finds some backrefs to update. The infinite loop in
del_pending_extents is due to a variable not properly
set. Thank you,
Hello,
There is a new feature 'uninitialized block groups' in ext4.
Block and inode bitmaps in uninitialized block groups are
uninitialized. This confuses the converter. The fix is call
ext2fs_new_inode for each block group at open time. It set
up uninitialized block and inode bitmaps
On Tue, 2009-01-20 at 00:28 +0800, Qinghuang Feng wrote:
kthread_run() returns the kthread or ERR_PTR(-ENOMEM), not NULL.
Thanks, got it.
-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Mon, 2009-01-19 at 22:19 +0800, Américo Wang wrote:
bit-radix.c should #include bit-radix.h, and add a missing declaration
for find_next_bit().
Signed-off-by: WANG Cong wangc...@zeuux.org
I fixed this a little differently, the bit-radix code wasn't being used
anymore. It's gone now ;)
On Mon, 2009-01-19 at 21:51 +0800, Américo Wang wrote:
- In bash, integer comparation should use '-eq', not '=='.
- Remove code for Mercurial, since btrfs now uses git.
version.sh should be removed from the mainline sources and only live in
the standalone tree. So, I'll apply this one a bit
On Mon, 2009-01-19 at 21:12 +0800, Américo Wang wrote:
On Mon, Jan 19, 2009 at 08:03:37AM -0500, Josef Bacik wrote:
On Mon, Jan 19, 2009 at 08:57:32PM +0800, Américo Wang wrote:
I found userspace tool, btrfsctl, uses BTRFS_VOL_NAME_MAX, and
it also looks that this one is more proper.
On Sun, 2009-01-18 at 09:12 -0500, Calvin Walton wrote:
On Sun, 2009-01-18 at 14:40 +0100, Peter Klotz wrote:
Calling btrfsctl results in this message when module btrfs.ko is not loaded:
r...@asus:/root# btrfsctl -A /dev/sda
ioctl:: Bad file descriptor
..
The output with applied
On Fri, 2008-12-19 at 13:14 -0800, Yehuda Sadeh Weinraub wrote:
This adds a new ioctl that requests for the csums of file's extent.
The csums of contiguous extents can also be requested. The call will
not return anything for extents that don't have csum information for
their data, or that the
So, I'd like to take this patch, but there is line wrapping and other
whitespace problems. Could you please send it with a mail client that
doesn't mangle? ;)
(Attaching it is fine too, at least on this list)
Attached both patches.
Thanks,
Yehuda
From
15 matches
Mail list logo
