> 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 noth
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
> acc
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 multiple given
> > arrays are independent and then give the loop
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
* 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:
> 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 heuristi
On Wed, Jan 21, 2009 at 10:54:18AM +0100, Andi Kleen wrote:
> > 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 poin
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 th
hello,
We should hold the block_group_cache_lock while modifying the
block groups red-black tree. Thank you,
Signed-off-by: Yan Zheng
---
diff -urp 1/fs/btrfs/extent-tree.c 2/fs/btrfs/extent-tree.c
--- 1/fs/btrfs/extent-tree.c2009-01-07 07:16:42.762364700 +0800
+++ 2/fs/btrfs/extent-tree.c
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,
Signe
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 appropriatel
Hello everyone,
There will be a btrfs conference call today January 21. Topics will
include mainline merging and testing results.
Time: 1:30pm US Eastern (10:30am Pacific)
* Dial-in Number(s):
* Toll Free: +1-888-967-2253
* Toll +1-650-607-2253
* Meeting id: 665734
* Passcode: 428737 (which h
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 in
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
>
I fixed this a little differently, the bit-radix code wasn't being used
anymore. It's gone now ;)
-chris
--
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 bi
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 p
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 ap
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 t
>
> 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 d7768ad789685150eb5d6fc94f1133f
On Tue, Jan 20, 2009 at 4:51 PM, Eric Sesterhenn wrote:
> I already tested squashfs. One issue is basically a problem with
> the zlib-api for which i just posted a patch here
> http://marc.info/?t=12321280733&r=1&w=2
>
Thanks for testing Squashfs. I've not ignored your emails, but I've
been
20 matches
Mail list logo
