On Tue, 13 Jan 2009 8:28:21 am Chris Mason wrote:
> Only mainline is definitive ;)
Oh ha ha! ;-)
> We'll have a tree with stable fixes that we want Linus to pull, and
> we'll have a development tree with unstable experimental stuff (these
> aren't yet named).
Ah, so for the moment stick with bt
Hello,
remove some unused lines.
--
Regards,
Zhu Yanhai
--
diff --git a/extent_io.c b/extent_io.c
index e086d40..5716e1e 100644
--- a/extent_io.c
+++ b/extent_io.c
@@ -1841,11 +1841,6 @@ static int submit_one_bio(int rw, struct bio
*bio, int mirror_num,
struct bio_vec *bvec = bio->bi_io_v
"Mike Snitzer" writes:
> On Sat, Jan 10, 2009 at 8:28 PM, Ingo Molnar wrote:
>>
>> Note, back when kdump was added to the kernel many moons ago i strongly
>> supported it and helped out with the patches, etc. I still think it might
>> have the potential to become big - but it needs a ton of tech
On Mon, 12 Jan 2009, Linus Torvalds wrote:
> code tends to get a lot more I$ and D$ misses. Deep call-chains _will_
I feel like an idiot that I never realized that "I$" meant
"instruction cache" until now :-p
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-b
On Mon, 2009-01-12 at 23:44 +, Daniel J Blueman wrote:
> Hi Chris et al,
>
> Firstly, BTRFS is progressing at a very healthy pace and seems to be a
> fantastic filesystem so far, and pulled into 2.6.29-rc1 is fine news
> indeed.
>
> Is there any plan to add BTRFS support to GRUB (v1 or 2)? I'
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>
> Too lazy to construct one myself, I googled for examples, and here's a
> trivial one that shows how it affects the ability of the compiler to
> eliminate memory references:
Do you really think this is realistic or even relevant?
The fact is
(a)
Hi Chris et al,
Firstly, BTRFS is progressing at a very healthy pace and seems to be a
fantastic filesystem so far, and pulled into 2.6.29-rc1 is fine news
indeed.
Is there any plan to add BTRFS support to GRUB (v1 or 2)? I've been
unable to find any information so far...
Many thanks,
Daniel
-
On Mon, 12 Jan 2009, Jamie Lokier wrote:
>
> Sometimes code motion makes code faster and/or smaller but use more
> stack space. If you want to keep the stack use down, it blocks some
> other optimisations.
Uhh. Yes. Compiling is an exercise in trade-offs.
That doesn't mean that you should try
Linus Torvalds wrote:
> But you'll need some background to it:
You paint a somewhat one-sided picture bordering on FUD.
> Type-based aliasing is _stupid_.
Type-based aliasing is simply an application of the language definition,
and depending on the compiled application and/or target architecture
Linus Torvalds wrote:
> > This is about storage allocation, not aliases. Storage allocation only
> > depends on lifetime.
>
> Well, the thing is, code motion does extend life-times, and if you think
> you can move stores across each other (even when you can see that they
> alias statically) due
On Tue, 2009-01-13 at 07:26 +1100, Chris Samuel wrote:
> Hi Chris,
>
> Now btrfs has made it into the mainline, which git tree is definitive now ?
Only mainline is definitive ;)
We'll have a tree with stable fixes that we want Linus to pull, and
we'll have a development tree with unstable experi
Hi Chris,
Now btrfs has made it into the mainline, which git tree is definitive now ?
cheers!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
signat
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>
> However, if the compiler chooses to put them into the same stack
> location, the RTL-based alias analysis will happily conclude (based on
> the differing types) that the reads from A and the writes to B can't
> possibly conflict, and some passes m
On Mon, 12 Jan 2009, Linus Torvalds wrote:
>
> Type-based aliasing is unacceptably stupid to begin with, and gcc took
> that stupidity to totally new heights by making it actually more important
> than even statically visible aliasing.
Btw, there are good forms of type-based aliasing.
The 'r
Linus Torvalds wrote:
>
> On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>> Something at the back of my mind said "aliasing".
>>
>> $ gcc linus.c -O2 -S ; grep subl linus.s
>> subl$1624, %esp
>> $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
>> subl$824, %esp
>>
>>
On Mon, 12 Jan 2009, H. Peter Anvin wrote:
>
> This is about storage allocation, not aliases. Storage allocation only
> depends on lifetime.
Well, the thing is, code motion does extend life-times, and if you think
you can move stores across each other (even when you can see that they
alias s
On Mon, 12 Jan 2009, Andi Kleen wrote:
>
> What I find nonsensical is that -fno-strict-aliasing generates
> better code here. Normally one would expect the compiler seeing
> more aliases with that option and then be more conservative
> regarding any sharing. But it seems to be the other way round
Andi Kleen wrote:
On Mon, Jan 12, 2009 at 11:02:17AM -0800, Linus Torvalds wrote:
Something at the back of my mind said "aliasing".
$ gcc linus.c -O2 -S ; grep subl linus.s
subl$1624, %esp
$ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
subl$824, %esp
That'
Hello everyone,
Btrfs v0.17 is now available. For download locations you can visit:
http://btrfs.wiki.kernel.org/
The main purpose of this release was to package up a btrfs-progs.tar.gz
that corresponds to the current code in the kernel.
In general, the disk format isn't going to change unless
On Mon, Jan 12, 2009 at 11:02:17AM -0800, Linus Torvalds wrote:
> > Something at the back of my mind said "aliasing".
> >
> > $ gcc linus.c -O2 -S ; grep subl linus.s
> > subl$1624, %esp
> > $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
> > subl$824, %esp
> >
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>
> Something at the back of my mind said "aliasing".
>
> $ gcc linus.c -O2 -S ; grep subl linus.s
> subl$1624, %esp
> $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
> subl$824, %esp
>
> That's with 4.3.2.
Interes
Andi Kleen wrote:
> On Sun, Jan 11, 2009 at 04:21:03PM -0800, Linus Torvalds wrote:
>>
>> On Mon, 12 Jan 2009, Andi Kleen wrote:
>>> so at least least for this case it works. Your case also doesn't work
>>> for me. So it looks like gcc didn't like something you did in your test
>>> program.
>> I
On Mon, 2009-01-12 at 19:33 +0200, Boaz Harrosh wrote:
> Which brings me back to my initial reaction to this work. Do we need
> two flavors of Mutex? some program sections need Fairness, some need
> performance. Some need low-latency, some need absolute raw CPU power.
Thing is, its the kernel, we
Peter Zijlstra wrote:
Spinlocks can use 'pure' MCS locks.
How about this, then. In mutex_lock(), keep wait_lock locked and only
release it when scheduling out. Waiter spinning naturally follows. If
spinlocks are cache friendly (are they today?) we inherit that. If
there is no contenti
Peter Zijlstra wrote:
> On Mon, 2009-01-12 at 08:20 -0800, Linus Torvalds wrote:
>> On Mon, 12 Jan 2009, Linus Torvalds wrote:
>>> You made it back into the locked version.
>> Btw, even if you probably had some reason for this, one thing to note is
>> that I think Chris' performance testing showed
On Mon, 2009-01-12 at 18:24 +0100, Peter Zijlstra wrote:
> On Mon, 2009-01-12 at 12:14 -0500, Chris Mason wrote:
> > On Mon, 2009-01-12 at 17:50 +0100, Peter Zijlstra wrote:
> > > >
> > > > (the file stat run is total run time, so lower is better. The other
> > > > numbers are files or MB per sec
Peter Zijlstra wrote:
On Mon, 2009-01-12 at 18:13 +0200, Avi Kivity wrote:
One thing that worries me here is that the spinners will spin on a
memory location in struct mutex, which means that the cacheline holding
the mutex (which is likely to be under write activity from the owner)
will b
On Mon, 2009-01-12 at 12:14 -0500, Chris Mason wrote:
> On Mon, 2009-01-12 at 17:50 +0100, Peter Zijlstra wrote:
> > >
> > > (the file stat run is total run time, so lower is better. The other
> > > numbers are files or MB per second, so higher is better)
> > >
> > > For the file create run, v8
On Mon, 2009-01-12 at 08:20 -0800, Linus Torvalds wrote:
>
> On Mon, 12 Jan 2009, Linus Torvalds wrote:
> >
> > You made it back into the locked version.
>
> Btw, even if you probably had some reason for this, one thing to note is
> that I think Chris' performance testing showed that the versio
On Mon, 2009-01-12 at 17:50 +0100, Peter Zijlstra wrote:
> >
> > (the file stat run is total run time, so lower is better. The other
> > numbers are files or MB per second, so higher is better)
> >
> > For the file create run, v8 had much lower system time than v7,
> > averaging 1s of sys time p
On Mon, 2009-01-12 at 18:13 +0200, Avi Kivity wrote:
> One thing that worries me here is that the spinners will spin on a
> memory location in struct mutex, which means that the cacheline holding
> the mutex (which is likely to be under write activity from the owner)
> will be continuously shar
On Mon, 2009-01-12 at 11:45 -0500, Chris Mason wrote:
> On Mon, 2009-01-12 at 08:20 -0800, Linus Torvalds wrote:
> >
> > On Mon, 12 Jan 2009, Linus Torvalds wrote:
> > >
> > > You made it back into the locked version.
> >
> > Btw, even if you probably had some reason for this, one thing to note
On Mon, 2009-01-12 at 08:20 -0800, Linus Torvalds wrote:
>
> On Mon, 12 Jan 2009, Linus Torvalds wrote:
> >
> > You made it back into the locked version.
>
> Btw, even if you probably had some reason for this, one thing to note is
> that I think Chris' performance testing showed that the versio
On Mon, 12 Jan 2009, Linus Torvalds wrote:
>
> You made it back into the locked version.
Btw, even if you probably had some reason for this, one thing to note is
that I think Chris' performance testing showed that the version using a
lock was inferior to his local btrfs hack, while the unlock
Peter Zijlstra wrote:
Subject: mutex: implement adaptive spinning
From: Peter Zijlstra
Date: Mon Jan 12 14:01:47 CET 2009
Change mutex contention behaviour such that it will sometimes busy wait on
acquisition - moving its behaviour closer to that of spinlocks.
This concept got ported to mainli
On Mon, 12 Jan 2009, Peter Zijlstra wrote:
>
> Change mutex contention behaviour such that it will sometimes busy wait on
> acquisition - moving its behaviour closer to that of spinlocks.
This version seems worse in so many ways.
You made the mutex bigger, for no obvious reason.
You made it b
Hi,
Remember to update 00-INDEX in the filesystems directory also :)
--
diff --git a/Documentation/filesystems/00-INDEX
b/Documentation/filesystems/00-INDEX
index 52cd611..1475cb5 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -18,6 +18,8 @@ befs.txt
Subject: mutex: implement adaptive spinning
From: Peter Zijlstra
Date: Mon Jan 12 14:01:47 CET 2009
Change mutex contention behaviour such that it will sometimes busy wait on
acquisition - moving its behaviour closer to that of spinlocks.
This concept got ported to mainline from the -rt tree, wh
On Mon, 2009-01-12 at 15:14 +, Miguel Figueiredo Mascarenhas Sousa
Filipe wrote:
> Hi,
>
> On Mon, Jan 12, 2009 at 1:58 PM, Chris Mason wrote:
> > On Sun, 2009-01-11 at 15:34 -0800, Andrew Morton wrote:
> >> http://bugzilla.kernel.org/show_bug.cgi?id=12435
> >>
>
> This is by far the biggest
Hi,
On Mon, Jan 12, 2009 at 1:58 PM, Chris Mason wrote:
> On Sun, 2009-01-11 at 15:34 -0800, Andrew Morton wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=12435
>>
This is by far the biggest issue btrfs has for simple/domestic users.
Its probably the most tested miss-feature of btrfs, somet
On Mon, 2009-01-12 at 11:31 +0100, Christian Hesse wrote:
> On Monday 12 January 2009, Gabor MICSKO wrote:
> > Hi,
> >
> > Since commit eecac8a148137ec5c519fc536effce8d6be89ec8
> >
> > ( HEAD is now at eecac8a... Btrfs: drop remaining LINUX_KERNEL_VERSION
> > checks and compat code )
> >
> > btrfs
Hello,
This patch fixes various bugs in btrfs-convert. These bugs
are mainly related to updating inode's isize and nbytes.
Signed-off-by: Yan Zheng
---
diff -urp btrfs-progs-orig/convert.c btrfs-progs/convert.c
--- btrfs-progs-orig/convert.c 2008-12-18 08:09:27.0 +0800
+++ btrfs-progs/
On Sun, 2009-01-11 at 15:34 -0800, Andrew Morton wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12435
>
> Congratulations ;)
Rejected documented, that's the best buzilla tag ever ;)
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
On Monday 12 January 2009, Gabor MICSKO wrote:
> Hi,
>
> Since commit eecac8a148137ec5c519fc536effce8d6be89ec8
>
> ( HEAD is now at eecac8a... Btrfs: drop remaining LINUX_KERNEL_VERSION
> checks and compat code )
>
> btrfs kernel module failed to compile on 2.6.27. Older kernel versions not
> suppo
Hi,
Since commit eecac8a148137ec5c519fc536effce8d6be89ec8
( HEAD is now at eecac8a... Btrfs: drop remaining LINUX_KERNEL_VERSION checks
and compat code )
btrfs kernel module failed to compile on 2.6.27. Older kernel versions not
supported anymore?
Thanks,
--
Gabor MICSKO - http://hup.hu
* Jamie Lokier wrote:
> Ingo Molnar wrote:
> > If it's used once in a single .c file it should be inlined even if
> > it's large.
>
> As Linus has pointed out, because of GCC not sharing stack among
> different inlined functions, the above is surprisingly not true.
Yes, but note that this has
46 matches
Mail list logo
