On Sun, 11 Jan 2009 11:26:41 pm David Woodhouse wrote:
> Sometimes you weren't going to get a backtrace if something goes wrong
> _anyway_.
Case in point - we've been struggling with some of our SuperMicro based
systems with AMD Barcelona B3 k10h CPUs *turning themselves off* when running
vario
Christian Hesse wrote:
On Sunday 11 January 2009, Peter Klotz wrote:
Since 2.6.29-rc1 contains btrfs I had to try it.
However the loopback mount of my btrfs formatted file fails:
u...@host:~$ dd if=/dev/zero of=btrfs.img bs=1MB count=512
u...@host:~$ mkfs.btrfs btrfs.img
fs created label (nul
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.
In kernel it's a problem due to raw stack usage.
In userspace ap
Andi Kleen wrote:
>
> Weird. I wonder where this strange restriction comes from. It indeed
> makes this much less useful than it could be :/
>
Most likely they're collapsing at too early of a stage.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't
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 very intent
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 very intentionally used _different_ types.
If you use the same type, gcc will apparenrly hap
On Sun, Jan 11, 2009 at 03:05:53PM -0800, Linus Torvalds wrote:
>
>
> On Sun, 11 Jan 2009, Linus Torvalds wrote:
> > On Sun, 11 Jan 2009, Andi Kleen wrote:
> > >
> > > Was -- i think that got fixed in gcc. But again only in newer versions.
> >
> > I doubt it. People have said that about a milli
http://bugzilla.kernel.org/show_bug.cgi?id=12435
Congratulations ;)
--
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 at http://vger.kernel.org/majordomo-info.html
On Sun, 11 Jan 2009, Linus Torvalds wrote:
> On Sun, 11 Jan 2009, Andi Kleen wrote:
> >
> > Was -- i think that got fixed in gcc. But again only in newer versions.
>
> I doubt it. People have said that about a million times, it has never
> gotten fixed, and I've never seen any actual proof.
I
On Fri, 09 Jan 2009 08:34:57 PST, "H. Peter Anvin" said:
> A lot of noise is being made about the naming of the levels (and I
> personally believe we should have a different annotation for "inline
> unconditionally for correctness" and "inline unconditionally for
> performance", as a documentation
Now that btrfs is in mainline, perhaps
a maintainers entry is appropriate?
Perhaps:
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f65a26..138a54c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1021,6 +1021,14 @@ M: m...@bu3sch.de
W: http://bu3sch.de/btgpio.php
S: Maintained
+BTR
Since 2.6.29-rc1 contains btrfs I had to try it.
However the loopback mount of my btrfs formatted file fails:
u...@host:~$ dd if=/dev/zero of=btrfs.img bs=1MB count=512
u...@host:~$ mkfs.btrfs btrfs.img
fs created label (null) on btrfs.img
nodesize 4096 leafsize 4096 sectorsize 4096 size 48
On Sun, 11 Jan 2009, Andi Kleen wrote:
>
> Was -- i think that got fixed in gcc. But again only in newer versions.
I doubt it. People have said that about a million times, it has never
gotten fixed, and I've never seen any actual proof.
I think that what got fixed was that gcc now at least re
On Sun, Jan 11, 2009 at 06:11:35PM +0800, Andreas Dilger wrote:
> I'm sad that netconsole/netdump never made it big. It was fairly useful,
> and extending the eth drivers to add the polling mode was trivial to do.
> We were using that for a few years, but it got replaced by kdump and it
> appears
> Isn't the ioctl switch stack issue a separate GCC bug?
>
> It was/is assigning assigning separate space for local variables which
Was -- i think that got fixed in gcc. But again only in newer versions.
> are mutually exclusive. So instead of the stack footprint of the
> function with the switc
On Sun, 2009-01-11 at 21:14 +0100, Andi Kleen wrote:
>
> On the other hand (my personal opinion, not shared by everyone) is
> that the ioctl switch stack issue is mostly only a problem with 4K
> stacks and in the rare cases when I still run 32bit kernels
> I never set that option because I consi
On Sun, Jan 11, 2009 at 11:25:32AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 11 Jan 2009, Andi Kleen wrote:
> >
> > The proposal was to use -fno-inline-functions-called-once (but
> > the resulting numbers were not promising)
>
> Well, the _optimal_ situation would be to not need it, because g
On Sun, 11 Jan 2009, Andi Kleen wrote:
>
> The proposal was to use -fno-inline-functions-called-once (but
> the resulting numbers were not promising)
Well, the _optimal_ situation would be to not need it, because gcc does a
good job without it. That implies trying to find a better balance bet
On Mon, Jan 12, 2009 at 1:52 AM, Qinghuang Feng wrote:
> Use the standard magic.h for btrfs and squashfs.
>
The patch can't be split to two pieces, otherwise it will conflict
because magic.h would be
modified twice.
So I also send it to akpm, he must have a good idea.
--
To unsubscribe from this l
On Sun, Jan 11, 2009 at 12:26:41PM +, David Woodhouse wrote:
> - Unconditionally have 'inline' meaning 'always_inline'. If we say it,
> we should mean it.
>
> - Resist the temptation to use -fno-inline-functions. Allow GCC to
> inline other things if it wants to.
The proposal was
Use the standard magic.h for btrfs and squashfs.
Signed-off-by: Qinghuang Feng
---
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 0a14b49..7256cf2 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "compat.h"
#incl
> 'kdump light' perhaps that dumps the most important data structures like
> registers of all CPUs, task struct and the symbol tables, the current task
> itself including the kernel stack plus the surrounding 4K of all pointers
> that are in current registers and that point into kernel memory -
On Sun, Jan 11, 2009 at 5:11 AM, Andreas Dilger wrote:
> On Jan 10, 2009 16:15 -0500, Theodore Ts'o wrote:
>> In my experience, there are very few kernel versions and hardware for
>> which kdump works. I've talked to the people who have to make kdump
>> work, and every 12-18 months, with a new s
On Sat, 2009-01-10 at 04:02 +0100, Andi Kleen wrote:
> Long term that problem will hopefully disappear, as gcc learns to do cross
> source file inlining (like a lot of other compilers already do)
We've already been able to get GCC doing this for the kernel, in fact
(the --combine -fwhole-program s
On Jan 10, 2009 16:15 -0500, Theodore Ts'o wrote:
> In my experience, there are very few kernel versions and hardware for
> which kdump works. I've talked to the people who have to make kdump
> work, and every 12-18 months, with a new set of enterprise kernels
> comes out, they have to go and fix
25 matches
Mail list logo
