Mike Snitzer snit...@gmail.com writes:
On Sat, Jan 10, 2009 at 8:28 PM, Ingo Molnar mi...@elte.hu 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
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 Sun, Jan 11, 2009 at 5:11 AM, Andreas Dilger adil...@sun.com 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,
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 to
* Linus Torvalds torva...@linux-foundation.org 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
* Linus Torvalds torva...@linux-foundation.org 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
* jim owens jow...@hp.com 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:
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
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
nothing Standard
On Fri, 09 Jan 2009 08:34:57 -0800
H. Peter Anvin h...@zytor.com 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 08:44:47 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org 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
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
--
H.
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, 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, 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
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, 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
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:
I
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 archives)
On Fri, 9 Jan 2009 18:47:19 +0100
Andi Kleen a...@firstfloor.org 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
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 -
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 don't
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
On Fri, Jan 9, 2009 at 6:54 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen a...@firstfloor.org 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
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
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:
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen a...@firstfloor.org 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
On Fri, Jan 09, 2009 at 08:10:20PM +0100, Richard Guenther wrote:
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen a...@firstfloor.org 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
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 optimise
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 segfault
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
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
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 back)
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
On Fri, 09 Jan 2009 14:35:29 -0800
H. Peter Anvin h...@zytor.com 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
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'm talking
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, 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 now
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 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 information
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
place
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/suse
43 matches
Mail list logo
