"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 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
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
> '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 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
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 and care to
> reach that level
* Mike Snitzer wrote:
> On Sat, Jan 10, 2009 at 10:34 AM, Ingo Molnar wrote:
> >
> > * Mike Snitzer wrote:
> >
> >> Yes, especially from someone who lacks the ability to properly
> >> configure kdump. I'm fairly surprised others are giving you a free
> >> pass when you keep asserting how br
* Linus Torvalds wrote:
> As far as I'm concerned, digital cameras have been more useful than
> kernel dumps to kernel debugging.
Yes, especially ones with VGA video capture. (I caught a
"oops+triple-fault" crash via that trick once, which was not
serial-console capture-able and which was ju
On Sat, 10 Jan 2009, Andi Kleen wrote:
>
> I think that's mostly because kexec from arbitary context is a
> somewhat unstable concept.
I think that's the understatement of the year.
We have tons of problems with standard suspend-to-ram, and that's when the
suspend sequence has done its best
> In my experience, there are very few kernel versions and hardware for
> which kdump works.
I think that's mostly because kexec from arbitary context is a
somewhat unstable concept. It requires all drivers to be able
to reinit the hardware from an arbitary state, and that's just
hard (it's kind
On Sat, Jan 10, 2009 at 01:21:06PM -0500, Mike Snitzer wrote:
> > In practice i rarely see bugfixes that were debugged via kdump. Normal
> > oops based fixes outnumber kdump based fixes by a ratio of 1:100 or worse
> > - and kdump is readily available these days - just nobody configures it.
>
> So
On Sat, Jan 10, 2009 at 10:34 AM, Ingo Molnar wrote:
>
> * Mike Snitzer wrote:
>
>> Yes, especially from someone who lacks the ability to properly configure
>> kdump. I'm fairly surprised others are giving you a free pass when you
>> keep asserting how broken kdump is with such hollow criticism.
* Mike Snitzer wrote:
> Yes, especially from someone who lacks the ability to properly configure
> kdump. I'm fairly surprised others are giving you a free pass when you
> keep asserting how broken kdump is with such hollow criticism. I rely
> heavily on kdump and it works quite well (kvm i
On Sat, Jan 10, 2009 at 1:44 AM, Nicholas Miell wrote:
> On Fri, 2009-01-09 at 20:05 -0800, Linus Torvalds wrote:
>>
>> On Fri, 9 Jan 2009, Nicholas Miell wrote:
>> >
>> > It's only too big if you always keep it in memory, and I wasn't
>> > suggesting that.
>>
>> Umm. We're talking kernel panics h
On Sat, 10 Jan 2009 6:56:02 am H. Peter Anvin wrote:
> This does bring up the idea of including a compiler with the kernel
> sources again, doesn't it?
Oh please don't give him any more ideas; first it was a terminal emulator that
had delusions of grandeur, then something to help him manage tha
On Fri, 2009-01-09 at 20:05 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Nicholas Miell wrote:
> >
> > It's only too big if you always keep it in memory, and I wasn't
> > suggesting that.
>
> Umm. We're talking kernel panics here. If it's not in memory, it doesn't
> exist as far as the
Arjan van de Ven wrote:
>
> thinking about this.. making a "pastebin" like thing for oopses is
> relatively trivial for me; all the building blocks I have already.
>
> The hard part is getting the vmlinux files in place. Right now I do
> this manually for popular released kernels.. if the fedora/
On Fri, 9 Jan 2009 14:52:33 -0500
Theodore Tso wrote:
> Kerneloops.org does this, so the code is mostly written; but it does
> this in a blinded fashion, so it only makes sense for oops which are
> very common and for which we don't need to ask the user, "so what were
> you doing at the time". I
On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> It's only too big if you always keep it in memory, and I wasn't
> suggesting that.
Umm. We're talking kernel panics here. If it's not in memory, it doesn't
exist as far as the kernel is concerned.
If it doesn't exist, it cannot be reported.
> My
On Fri, 2009-01-09 at 16:05 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> > In the general case is it does nothing at all to debugging (beyond the
> > usual weird control flow you get from any optimized code) -- the
> > compiler generates line number information f
> I thought -Os actually disabled the basic-block reordering, doesn't it?
Not in current gcc head no (just verified by stepping through)
>
> And I thought it did that exactly because it generates bigger code and
> much worse I$ patterns (ie you have a lot of "conditional branch to other
> pla
On Sat, 10 Jan 2009, Andi Kleen wrote:
>
> > What's the cost/benefit of that 4%? Does it actually improve performance?
> > Especially if you then want to keep DWARF unwind information in memory in
> > order to fix up some of the problems it causes? At that point, you lost
>
> dwarf unwind inf
> What's the cost/benefit of that 4%? Does it actually improve performance?
> Especially if you then want to keep DWARF unwind information in memory in
> order to fix up some of the problems it causes? At that point, you lost
dwarf unwind information has nothing to do with this, it doesn't tell
On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> So take your complaint about gcc's decision to inline functions called
> once.
Actually, the "called once" really is a red herring. The big complaint is
"too aggressively when not asked for". It just so happens that the called
once logic is right
On Fri, Jan 09, 2009 at 11:44:10PM +0100, Andi Kleen wrote:
> > Fetch a gigabyte's worth of data for the debuginfo RPM?
>
> The suse 11.0 kernel debuginfo is ~120M.
How is this debuginfo generated?
Someone have posted the following patch which I did not apply in lack
of any real need. But maybe
On Fri, 2009-01-09 at 12:29 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Nicholas Miell wrote:
> >
> > Maybe the kernel's backtrace code should be fixed instead of blaming
> > gcc.
>
> And maybe people who don't know what they are talking about shouldn't
> speak?
I may not know what I'
On Fri, 09 Jan 2009 14:35:29 -0800
"H. Peter Anvin" wrote:
> Andi Kleen wrote:
> >> Fetch a gigabyte's worth of data for the debuginfo RPM?
> >
> > The suse 11.0 kernel debuginfo is ~120M.
>
> Still, though, hardly worth doing client-side when it can be done
> server-side for all the common d
Andi Kleen wrote:
Fetch a gigabyte's worth of data for the debuginfo RPM?
The suse 11.0 kernel debuginfo is ~120M.
Still, though, hardly worth doing client-side when it can be done
server-side for all the common distro kernels. For custom kernels, not
so, but there you should already have
> Fetch a gigabyte's worth of data for the debuginfo RPM?
The suse 11.0 kernel debuginfo is ~120M.
-Andi
--
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.
On Fri, 9 Jan 2009 14:52:33 -0500
Theodore Tso wrote:
> On Fri, Jan 09, 2009 at 07:55:09PM +0100, Andi Kleen wrote:
> > > But _users_ just get their oopses sent automatically. So it's not
> > > about
> >
> > If they send it from distro kernels the automated oops sender could
> > just fetch the
On Fri, 9 Jan 2009, Theodore Tso wrote:
> I'm beginning to think that for the kernel, we should just simply
> remove CONFIG_OPTIMIZE_INLINING (so that inline means
> "always_inline"), and -fno-inline-functions
> -fno-inline-functions-called-one (so that gcc never inlines functions
> behind our ba
I'm beginning to think that for the kernel, we should just simply
remove CONFIG_OPTIMIZE_INLINING (so that inline means
"always_inline"), and -fno-inline-functions
-fno-inline-functions-called-one (so that gcc never inlines functions
behind our back) --- and then we create tools that count how many
>
> And you do have to realize that Linux has been using gcc for a _loong_
> while. You can talk all you want about how "inline" is just a hint, but
> the fact is, it didn't use to be. gcc people _made_ it so, and are having
> a damn hard time admitting that it's causing problems.
The kernel h
On Fri, Jan 9, 2009 at 9:26 PM, Linus Torvalds
wrote:
>
>
> On Fri, 9 Jan 2009, Richard Guenther wrote:
>>
>> This is a case where the improved IPA-CP (interprocedural constant
>> propagation) of GCC 4.4 may help. In general GCC cannot say how a call
>> argument may affect optimization if the fun
On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> Maybe the kernel's backtrace code should be fixed instead of blaming
> gcc.
And maybe people who don't know what they are talking about shouldn't
speak?
You just loaded the whole f*cking debug info just to do that exact
analysis. Guess how big it
On Fri, 9 Jan 2009, Nicholas Miell wrote:
> On Fri, 2009-01-09 at 08:28 -0800, Linus Torvalds wrote:
> >
> > We get oopses that have a nice symbolic back-trace, and it reports an
> > error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined
> > things to the point that only an exper
On Fri, 9 Jan 2009, Richard Guenther wrote:
>
> This is a case where the improved IPA-CP (interprocedural constant
> propagation) of GCC 4.4 may help. In general GCC cannot say how a call
> argument may affect optimization if the function was inlined, so the
> size estimates are done with ju
On Fri, 2009-01-09 at 08:28 -0800, Linus Torvalds wrote:
>
> We get oopses that have a nice symbolic back-trace, and it reports an
> error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined
> things to the point that only an expert can realize "oh, the bug was
> actually five hundre
On Fri, Jan 9, 2009 at 8:44 PM, Linus Torvalds
wrote:
>
>
> On Fri, 9 Jan 2009, Richard Guenther wrote:
>>
>> -fno-inline-functions-called-once disables the heuristic that always
>> inlines (static!) functions that are called once. Other heuristics
>> still apply, like inlining the static functio
Linus Torvalds wrote:
Because then they are _our_ mistakes, not some random compiler version that
throws a dice!
This does bring up the idea of including a compiler with the kernel
sources again, doesn't it?
-hpa (ducks & runs)
--
To unsubscribe from this list: send the line "unsub
On Fri, Jan 09, 2009 at 07:55:09PM +0100, Andi Kleen wrote:
> > But _users_ just get their oopses sent automatically. So it's not about
>
> If they send it from distro kernels the automated oops sender could
> just fetch the debuginfo rpm and decode it down to a line.
> My old automatic user segf
On Fri, 9 Jan 2009, Matthew Wilcox wrote:
>
> Now, I'm not going to argue the directIO code is a shining example of
> how we want things to look, but we don't really want ten arguments
> being marshalled into a function call; we want gcc to inline the
> direct_io_worker() and do its best to opti
On Fri, 9 Jan 2009, Richard Guenther wrote:
>
> -fno-inline-functions-called-once disables the heuristic that always
> inlines (static!) functions that are called once. Other heuristics
> still apply, like inlining the static function if it is small.
> Everything else would be totally stupi
On Fri, Jan 9, 2009 at 8:40 PM, Andi Kleen wrote:
> On Fri, Jan 09, 2009 at 08:10:20PM +0100, Richard Guenther wrote:
>> On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
>> >> GCC 4.3 should be good in compiling the
>> >> kernel with default -Os settings.
>> >
>> > It's unfortunately not. It doe
On Fri, Jan 09, 2009 at 08:35:06PM +0100, Andi Kleen wrote:
> - Also inline everything static that is only called once
> [on the theory that this shrinks code size which is true
> according to my measurements]
>
> -fno-inline-functions-called once disables this new rule.
> It's very well and clear
On Fri, Jan 09, 2009 at 08:10:20PM +0100, Richard Guenther wrote:
> On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
> >> GCC 4.3 should be good in compiling the
> >> kernel with default -Os settings.
> >
> > It's unfortunately not. It doesn't inline a lot of simple asm() inlines
> > for example.
Richard Guenther wrote:
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
GCC 4.3 should be good in compiling the
kernel with default -Os settings.
It's unfortunately not. It doesn't inline a lot of simple asm() inlines
for example.
Reading Ingos posting with the actual numbers states the op
> What happens when you say -fno-inline-functions-called-once? Does it
> disable inlining for those functions IN GENERAL, or just for the LARGE
It does disable it in general, unless they're marked inline explicitely :
The traditional gcc 2.x rules were:
I Only inline what is marked inline (but
Richard Guenther wrote:
But it's also not inconceivable that gcc adds a -fkernel-inlining or
similar that changes the parameters if we ask nicely. I suppose
actually such a parameter would be useful for far more programs
than the kernel.
I think that the kernel is a perfect target to optimize
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
>> GCC 4.3 should be good in compiling the
>> kernel with default -Os settings.
>
> It's unfortunately not. It doesn't inline a lot of simple asm() inlines
> for example.
Reading Ingos posting with the actual numbers states the opposite.
Richard.
On Fri, Jan 9, 2009 at 6:54 PM, Linus Torvalds
wrote:
>
>
> On Fri, 9 Jan 2009, Matthew Wilcox wrote:
>>
>> That seems like valuable feedback to give to the GCC developers.
>
> Well, one thing we should remember is that the kernel really _is_ special.
(sorry for not threading properly here)
Linu
> GCC 4.3 should be good in compiling the
> kernel with default -Os settings.
It's unfortunately not. It doesn't inline a lot of simple asm() inlines
for example.
-Andi
--
a...@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> Ok you're saying we should pay the 4.1% by default for this?
The thing is, YOU ARE MAKING THAT NUMBER UP!
First off, the size increase only matters if it actually increases the
cache footprint. And it may, but..
Secondly, my whole point here has been
On Fri, Jan 9, 2009 at 7:19 PM, Andi Kleen wrote:
>> So we do have special issues. And exactly _because_ we have special issues
>> we should also expect that some compiler defaults simply won't ever really
>> be appropriate for us.
>
> I agree that the kernel needs quite different inlining heurist
> But _users_ just get their oopses sent automatically. So it's not about
If they send it from distro kernels the automated oops sender could
just fetch the debuginfo rpm and decode it down to a line.
My old automatic user segfault uploader I did originally
for the core pipe code did that too.
>
Linus Torvalds wrote:
So we do have special issues. And exactly _because_ we have special issues
we should also expect that some compiler defaults simply won't ever really
be appropriate for us.
That is, of course, true.
However, the Linux kernel (and quite a few other kernels) is a very
> So we do have special issues. And exactly _because_ we have special issues
> we should also expect that some compiler defaults simply won't ever really
> be appropriate for us.
I agree that the kernel needs quite different inlining heuristics
than let's say a template heavy C++ program. I gues
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> Universal noinline would also be a bad idea because of its
> costs (4.1% text size increase). Perhaps should make it
> a CONFIG option for debugging though.
That's _totally_ the wrong way.
If you can reproduce an issue on your machine, you generally do
On Fri, 9 Jan 2009, Matthew Wilcox wrote:
>
> That seems like valuable feedback to give to the GCC developers.
Well, one thing we should remember is that the kernel really _is_ special.
The kernel not only does things no other program tends to do (inline asms
are unusual in the first place -
> I think that's the point. gcc will not get it right.
I don't think that's necessary an universal truth. It
can be probably fixed.
> So we need to do it ourselves in the kernel sources.
> We may not like it, but it's the only way to guarantee reproducable
> reliable inline / noinline decisions
On Fri, 9 Jan 2009 18:47:19 +0100
Andi Kleen wrote:
> On Fri, Jan 09, 2009 at 10:28:01AM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> > > Also cc Honza in case he has comments (you might want
> > > to review more of the thread in the archives)
>
On Fri, Jan 09, 2009 at 06:47:19PM +0100, Andi Kleen wrote:
> On Fri, Jan 09, 2009 at 10:28:01AM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> > > Also cc Honza in case he has comments (you might want
> > > to review more of the thread in the archive
On Fri, Jan 09, 2009 at 10:28:01AM -0700, Matthew Wilcox wrote:
> On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> > Also cc Honza in case he has comments (you might want
> > to review more of the thread in the archives)
>
> I think this particular bug is already known and discussed:
On Fri, Jan 09, 2009 at 09:11:47AM -0800, Linus Torvalds wrote:
> IIRC, the numbers mean different things for different versions of gcc, and
> I think using the parameters was very strongly discouraged by gcc
> developers. IOW, they were meant for gcc developers internal tuning
> efforts, not re
On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> Also cc Honza in case he has comments (you might want
> to review more of the thread in the archives)
I think this particular bug is already known and discussed:
http://gcc.gnu.org/ml/gcc/2008-12/msg00365.html
and it hints at being f
> I vote for the, get rid of the current inline, rename __always_inline to
There is some code that absolutely requires inline for correctness,
like the x86-64 vsyscall code. I would advocate to keep the
explicit __always_inline at least there to make it very clear.
> inline, and then remove all
On Fri, 9 Jan 2009, Steven Rostedt wrote:
>
> I vote for the, get rid of the current inline, rename __always_inline to
> inline, and then remove all non needed inlines from the kernel.
This is what we do all the time, and historically have always done.
But
- CONFIG_OPTIMIZE_INLINING=y screws
On Fri, Jan 09, 2009 at 09:03:12AM -0500, jim owens wrote:
> They also know inlining may increase program object size.
> That inlining will reduce object size on many architectures
> if the function is small is just a happy side effect to them.
The problem is that the threshold for that is archite
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> There's also one alternative: gcc's inlining algorithms are extensibly
> tunable with --param. We might be able to find a set of numbers that
> make it roughly work like we want it by default.
We tried that.
IIRC, the numbers mean different things for
On Fri, 9 Jan 2009, H. Peter Anvin wrote:
> Dirk Hohndel wrote:
> >
> > Does gcc actually follow the "promise"? If that's the case (and if it's
> > considered a bug when it doesn't), then we can get what Linus wants by
> > annotating EVERY function with either __always_inline or noinline.
> >
>
On Fri, Jan 09, 2009 at 08:46:20AM -0800, Dirk Hohndel wrote:
> On Fri, 09 Jan 2009 08:34:57 -0800
> "H. Peter Anvin" wrote:
> >
> > As far as naming is concerned, gcc effectively supports four levels,
> > which *currently* map onto macros as follows:
> >
> > __always_inline Inline u
Dirk Hohndel wrote:
>
> Does gcc actually follow the "promise"? If that's the case (and if it's
> considered a bug when it doesn't), then we can get what Linus wants by
> annotating EVERY function with either __always_inline or noinline.
>
__always_inline and noinline does work.
-hpa
-
On Fri, 9 Jan 2009 08:44:47 -0800 (PST)
Linus Torvalds wrote:
> On Fri, 9 Jan 2009, H. Peter Anvin wrote:
> > As far as naming is concerned, gcc effectively supports four levels,
> > which *currently* map onto macros as follows:
> >
> > __always_inline Inline unconditionally
> > inlin
On Fri, 09 Jan 2009 08:34:57 -0800
"H. Peter Anvin" wrote:
>
> As far as naming is concerned, gcc effectively supports four levels,
> which *currently* map onto macros as follows:
>
> __always_inline Inline unconditionally
> inlineInlining hint
>
On Fri, 9 Jan 2009, H. Peter Anvin wrote:
> As far as naming is concerned, gcc effectively supports four levels,
> which *currently* map onto macros as follows:
>
> __always_inline Inline unconditionally
> inlineInlining hint
> Standard heuristi
Ingo Molnar wrote:
>
> My goal is to make the kernel smaller and faster, and as far as the
> placement of 'inline' keywords goes, i dont have too strong feelings about
> how it's achieved: they have a certain level of documentation value
> [signalling that a function is _intended_ to be lightwe
On Fri, 9 Jan 2009, Ingo Molnar wrote:
>
> Core kernel developers tend to be quite inline-conscious and generally do
> not believe that making something inline will make it go faster.
Some of us core kernel developers tend to believe that:
- inlining is supposed to work like macros, and shou
* jim owens wrote:
> Ingo Molnar wrote:
>>
>> One interpretation of the numbers would be that core kernel hackers are
>> more inline-happy, maybe because they think that their functions are
>> more important to inline.
>>
>> Which is generally a fair initial assumption, but according to the
>
* Ingo Molnar wrote:
> > I suspect gcc has some pre-inlining heuristics that don't take
> > constant folding and simplifiation into account - if you look at just
> > the raw tree of the function without taking the optimization into
> > account, it will look big.
>
> Yeah. In my tests GCC 4.3
Ingo Molnar wrote:
One interpretation of the numbers would be that core kernel hackers are
more inline-happy, maybe because they think that their functions are more
important to inline.
Which is generally a fair initial assumption, but according to the numbers
it does not appear to pay off
* Linus Torvalds wrote:
> 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" stat
82 matches
Mail list logo
