> foo()
> {
> char a[1000];
> }
>
> bar()
> {
> char a[1000];
> }
>
> zot()
> {
> foo();
> bar();
> }
>
> uses 2000 bytes of stack.
> And with the right compiler version.
I believe that's fixed in newer gcc versions.
For old gccs we might indeed need to add noinlines th
On Thu, Jan 08, 2009 at 07:42:48PM -0800, Linus Torvalds wrote:
> > I actually often use noinline when developing code simply because it
> > makes it easier to read oopses when gcc doesn't inline ever static
> > (which it normally does if it only has a single caller)
>
> Yes. Gcc inlining is a to
On Fri, 9 Jan 2009 04:35:31 +0100 Andi Kleen wrote:
> On Thu, Jan 08, 2009 at 05:44:25PM -0800, H. Peter Anvin wrote:
> > Harvey Harrison wrote:
> > >>
> > >> We might still try the second or third options, as i think we shouldnt
> > >> go
> > >> back into the business of managing the inline at
Harvey Harrison wrote:
>
> A lot of code was written assuming inline means __always_inline, I'd suggest
> keeping that assumption and working on removing inlines that aren't
> strictly necessary as there's no way to know what inlines meant 'try to
> inline'
> and what ones really should have been
Linus Torvalds wrote:
>
> First off, gcc _does_ have a perfectly fine notion of how heavy-weight an
> "asm" statement is: just count it as a single instruction (and count the
> argument setup cost that gcc _can_ estimate).
>
True. It's not what it's doing, though. It looks for '\n' and ';'
c
From: Linus Torvalds
Date: Thu, 8 Jan 2009 19:46:30 -0800 (PST)
> First off, gcc _does_ have a perfectly fine notion of how heavy-weight an
> "asm" statement is: just count it as a single instruction (and count the
> argument setup cost that gcc _can_ estimate).
Actually, at least at one point
On Thu, 8 Jan 2009, H. Peter Anvin wrote:
>
> Right. gcc simply doesn't have any way to know how heavyweight an
> asm() statement is
I don't think that's relevant.
First off, gcc _does_ have a perfectly fine notion of how heavy-weight an
"asm" statement is: just count it as a single instruc
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> I actually often use noinline when developing code simply because it
> makes it easier to read oopses when gcc doesn't inline ever static
> (which it normally does if it only has a single caller)
Yes. Gcc inlining is a total piece of sh*t.
Gcc doesn't
On Thu, Jan 08, 2009 at 05:44:25PM -0800, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> >>
> >> We might still try the second or third options, as i think we shouldnt go
> >> back into the business of managing the inline attributes of ~100,000
> >> kernel functions.
> >
> > Or just make it cl
thanks. I got it.
Shen
on 01/08/2009 07:49 PM, Yan Zheng wrote:
> 2009/1/8 Shen Feng :
>> Hello,
>>
>> I tried to ceate a snapshot of a subvol.
>> But it seems now work.
>>
>> Please see the test below. I think the file created by dd
>> should also in the snap directory.
>>
>
> This is the expec
On Thu, 2009-01-08 at 17:44 -0800, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> >>
> >> We might still try the second or third options, as i think we shouldnt go
> >> back into the business of managing the inline attributes of ~100,000
> >> kernel functions.
> >
> > Or just make it clear tha
Harvey Harrison wrote:
>>
>> We might still try the second or third options, as i think we shouldnt go
>> back into the business of managing the inline attributes of ~100,000
>> kernel functions.
>
> Or just make it clear that inline shouldn't (unless for a very good reason)
> _ever_ be used in
Andi Kleen wrote:
>> I'll try to annotate the inline asms (there's not _that_ many of them),
>> and measure what the size impact is.
>
> You can just use the patch I submitted and that you rejected for
> most of them :)
I just ran a sample build for x86-64 with gcc 4.3.0, these all
allyesconfig
Chris Mason wrote:
Unresolved from this reviewing thread:
* Should it be named btrfsdev? My vote is no, it is extra work for the
distros when we finally do rename it, and I don't think btrfs really has
the reputation for stability right now. But if Linus or Andrew would
prefer the dev on ther
>
> The problem? Setting "lock->count" to 0. That will mean that the next
> "mutex_unlock()" will not necessarily enter the slowpath at all, and won't
> necessarily wake things up like it should.
>
> Normally we set lock->count to 0 after getting the lock, and only _inside_
> the spinlock, an
On Thu, 2009-01-08 at 19:33 +0100, Ingo Molnar wrote:
> * Linus Torvalds wrote:
> >
> > Ingo - I think we need to remove that crap again. Because gcc gets the
> > inlining horribly horribly wrong. As usual.
>
> Apparently it messes up with asm()s: it doesnt know the contents of the
> asm()
On Thu, 8 Jan 2009, Chris Mason wrote:
>
> The patch below isn't quite what Linus suggested, but it is working here
> at least. In every test I've tried so far, this is faster than the ugly
> btrfs spin.
Sadly, I don't think it's really working.
I was pretty sure that adding the unlocked loop
On Thu, 8 Jan 2009, Chris Mason wrote:
> On Thu, 2009-01-08 at 13:14 -0500, Steven Rostedt wrote:
> >
> > If it was the current process that preempted the owner and these are RT
> > tasks pinned to the same CPU and the owner is of lower priority than the
> > spinner, we have a deadlock!
> >
>
On Thu, 2009-01-08 at 11:13 -0800, Linus Torvalds wrote:
>
> Well, at least we do unless you enable that broken paravirt support. I'm
> not at all clear on why CONFIG_PARAVIRT wants to use inferior locks, but I
> don't much care.
Because the virtual cpu that has the ticket might not get schedul
On Thu, 2009-01-08 at 13:14 -0500, Steven Rostedt wrote:
>
>
> On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > > In fact, you might not even need a process C: all you need is for B to be
> > > on the same runqueue as A, and having enough load on the other CPU's that
> > > A never gets migrated aw
On Thu, 8 Jan 2009, Chris Mason wrote:
>
> It is less fair though, the 50 proc parallel creates had a much bigger
> span between the first and last proc's exit time. This isn't a huge
> shock, I think it shows the hot path is closer to a real spin lock.
Actually, the real spin locks are now fa
On Thu, 2009-01-08 at 13:27 -0500, Chris Mason wrote:
> On Thu, 2009-01-08 at 10:16 -0800, Linus Torvalds wrote:
> >
> > On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > >
> > > Ouch! I think you are on to something:
> >
> > Yeah, there's somethign there, but looking at Chris' backtrace, there's
>
> I'll try to annotate the inline asms (there's not _that_ many of them),
> and measure what the size impact is.
You can just use the patch I submitted and that you rejected for
most of them :)
-Andi
--
a...@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btr
Ingo Molnar wrote:
>
> Apparently it messes up with asm()s: it doesnt know the contents of the
> asm() and hence it over-estimates the size [based on string heuristics]
> ...
>
Right. gcc simply doesn't have any way to know how heavyweight an
asm() statement is, and it WILL do the wrong thin
* Linus Torvalds wrote:
> Unrelated:
>
> On Thu, 8 Jan 2009, Chris Mason wrote:
> >
> > RIP: 0010:[] [] __cmpxchg+0x36/0x3f
>
> Ouch. HOW THE HELL DID THAT NOT GET INLINED?
>
> cmpxchg() is a _single_ instruction if it's inlined, but it's a horrible
> mess of dynamic conditionals on the (co
On Thu, 2009-01-08 at 10:16 -0800, Linus Torvalds wrote:
>
> On Thu, 8 Jan 2009, Steven Rostedt wrote:
> >
> > Ouch! I think you are on to something:
>
> Yeah, there's somethign there, but looking at Chris' backtrace, there's
> nothing there to disable preemption. So if it was this simple case,
On Thu, 8 Jan 2009, Steven Rostedt wrote:
>
> Ouch! I think you are on to something:
Yeah, there's somethign there, but looking at Chris' backtrace, there's
nothing there to disable preemption. So if it was this simple case, it
should still have preempted him to let the other process run and
On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > In fact, you might not even need a process C: all you need is for B to be
> > on the same runqueue as A, and having enough load on the other CPU's that
> > A never gets migrated away. So "C" might be in user space.
You're right about not needing p
On Thu, 8 Jan 2009, Linus Torvalds wrote:
>
> And I don't even believe that is the bug. I suspect the bug is simpler.
>
> I think the "need_resched()" needs to go in the outer loop, or at least
> happen in the "!owner" case. Because at least with preemption, what can
> happen otherwise is
>
Unrelated:
On Thu, 8 Jan 2009, Chris Mason wrote:
>
> RIP: 0010:[] [] __cmpxchg+0x36/0x3f
Ouch. HOW THE HELL DID THAT NOT GET INLINED?
cmpxchg() is a _single_ instruction if it's inlined, but it's a horrible
mess of dynamic conditionals on the (constant - per call-site) size
argument if it
On Thu, 8 Jan 2009, Steven Rostedt wrote:
>
> We keep spinning if the owner changes.
I think we want to - if you have multiple CPU's and a heavily contended
lock that acts as a spinlock, we still _do_ want to keep spinning even if
another CPU gets the lock.
And I don't even believe that is t
On Thu, 8 Jan 2009, Chris Mason wrote:
> On Thu, 2009-01-08 at 08:58 -0800, Linus Torvalds wrote:
> >
> > Ok, I've gone through -v7, and I'm sure you're all shocked to hear it, but
> > I have no complaints. Except that you dropped all the good commit
> > commentary you had earlier ;)
> >
>
>
On Thu, 2009-01-08 at 08:58 -0800, Linus Torvalds wrote:
>
> Ok, I've gone through -v7, and I'm sure you're all shocked to hear it, but
> I have no complaints.
*cheer*, except I guess we need to figure out what goes bad for Chris.
> Except that you dropped all the good commit
> commentary you
On Thu, 2009-01-08 at 08:58 -0800, Linus Torvalds wrote:
>
> Ok, I've gone through -v7, and I'm sure you're all shocked to hear it, but
> I have no complaints. Except that you dropped all the good commit
> commentary you had earlier ;)
>
Seems to get stuck under load. I've hit it with make -j
Ok, I've gone through -v7, and I'm sure you're all shocked to hear it, but
I have no complaints. Except that you dropped all the good commit
commentary you had earlier ;)
The patch looks pretty good (except for the big "#if 0" block in
mutex-debug.c that I hope gets fixed, but I can't even re
Post wiki pointer message for getting version
status, limitations, and known problems.
Signed-off-by: jim owens
---
mkfs.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/mkfs.c b/mkfs.c
index cb21db6..d664254 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -403,6 +403,9 @@ int
On Thu, 8 Jan 2009, Peter Zijlstra wrote:
>
> This was done because the interaction between trylock_slowpath and that
> -1000 state hurt my head.
Yeah, it was a stupid hacky thing to avoid the "list_empty()", but doing
it explicitly is fine (we don't hold the lock, so the list isn't
necessari
On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > > > + /*
> > > > +* We need to validate that we can do a
> > > > +* get_cpu() and that we have the percpu area.
> > > > +*/
> > > > + if (!cpu_online(cpu))
> > > > + goto out;
> > >
> > > Should we nee
On Thu, 2009-01-08 at 10:28 -0500, Steven Rostedt wrote:
> On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> > in the unlikely case we schedule(), that seems expensive enough to want
> > to make the spin case ever so slightly faster.
>
> OK, that makes sense, but I would comment that. Otherwise, it jus
On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> On Thu, 2009-01-08 at 10:09 -0500, Steven Rostedt wrote:
> > On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> > > Index: linux-2.6/kernel/sched.c
> > > ===
> > > --- linux-2.6.orig/kernel/sched.
On Thu, 2009-01-08 at 10:09 -0500, Steven Rostedt wrote:
> On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> > Index: linux-2.6/kernel/sched.c
> > ===
> > --- linux-2.6.orig/kernel/sched.c
> > +++ linux-2.6/kernel/sched.c
> > @@ -4672,6 +467
On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> Index: linux-2.6/kernel/sched.c
> ===
> --- linux-2.6.orig/kernel/sched.c
> +++ linux-2.6/kernel/sched.c
> @@ -4672,6 +4672,72 @@ need_resched_nonpreemptible:
> }
> EXPORT_SYMBOL(schedule)
On Thu, 2009-01-08 at 15:18 +0100, Ingo Molnar wrote:
> [ A detail, -tip testing found that the patch breaks mutex debugging:
>
> =
> [ BUG: bad unlock balance detected! ]
> -
> swapper/0 is trying to release lock (cp
> Sure, it probably is a non issue, but I'm afraid that non issues of today
> might become issues of tomorrow. Where does it say that we can never put a
> task struct in a movable zone.
Task structs are not movable, so they by definition do not belong
in movable zones.
> memory local to it, and
Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
>
>> * WOW *
>>
>
> WOW indeed - and i can see a similar _brutal_ speedup on two separate
> 16-way boxes as well:
>
> 16 CPUs, running 128 parallel test-tasks.
>
> NO_OWNER_SPIN:
> avg ops/sec: 281595
>
> OWNER_SPIN:
>
On Thu, 8 Jan 2009, Andi Kleen wrote:
> > What about memory hotplug as Ingo mentioned?
> >
> > Should that be:
> >
> > #if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_MEMORY_HOTPLUG)
>
> We expect memory hotunplug to only really work in movable zones
> (all others should at least have on
* Peter Zijlstra wrote:
> On Wed, 2009-01-07 at 15:10 -0800, Linus Torvalds wrote:
>
> > Please take all my patches to be pseudo-code. They've neither been
> > compiled nor tested, and I'm just posting them in the hope that somebody
> > else will then do things in the direction I think is the
2009/1/8 Shen Feng :
> Hello,
>
> I tried to ceate a snapshot of a subvol.
> But it seems now work.
>
> Please see the test below. I think the file created by dd
> should also in the snap directory.
>
This is the expected behaviour. Following link describes what
snapshot is.
http://en.wikipedia.
On Wed, 2009-01-07 at 15:10 -0800, Linus Torvalds wrote:
> Please take all my patches to be pseudo-code. They've neither been
> compiled nor tested, and I'm just posting them in the hope that somebody
> else will then do things in the direction I think is the proper one ;)
Linux opteron 2.6.28-
Hello,
I tried to ceate a snapshot of a subvol.
But it seems now work.
Please see the test below. I think the file created by dd
should also in the snap directory.
[r...@localhost mnt]# ./test2.sh
+ mkfs.btrfs /dev/sdb8
fs created label (null) on /dev/sdb8
nodesize 4096 leafsize 4096 s
50 matches
Mail list logo
