Re: [RFC PATCH 0/8]: uninline & uninline
> Is it possible to catch this automatically, like, by re-defining > likely/unlikely to the raw form in specific file(s)? Sure it would be possible to define a IN_VDSO symbol in all vdso related files and then do that. Might be useful for other things too. vdso has some very specific requirements. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 0/8]: uninline & uninline
> > Is there any reason they couldn't just be merged to mainline? > > > > I think it's a useful facility. > > ummm, now why did we made that decision... I think we decided that > it's the sort of thing which one person can run once per few months > and that will deliver its full value. I can maintain it in -mm and > we're happy - no need to add it to mainline. No strong feelings > either way really. Apparently nobody has been doing it for a while. :-) Last time I did it it was around the submission time and I actually patched it into mainline kernel to do so. Not particularly hard to do, but sitting in mm-only does make it a bit harder, and there are the vdso problem you just mentioned that one has to fix for himself if it exists in mainline. > It does have the downside that the kernel explodes if someone adds > unlikely or likely to the vdso code and I need to occasionally hunt > down new additions and revert them in that patch. That makes it a > bit of a maintenance burden. Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Hua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline & uninline
On Sat, 23 Feb 2008 14:15:06 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > >> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR > > > > This is a surprise. I expect that the -mm-only > > profile-likely-unlikely-macros.patch is the cause of this and mainline > > doesn't have this problem. > > Shouldn't they only have overhead when the respective CONFIG is enabled? yup. > > If true, then this likely/unlikely bloat has probably spread into a lot of > > your other results and it all should be redone against mainline, sorry :( > > > > (I'm not aware of anyone having used profile-likely-unlikely-macros.patch > > in quite some time. That's unfortunate because it has turned up some > > fairly flagrant code deoptimisations) > > Is there any reason they couldn't just be merged to mainline? > > I think it's a useful facility. ummm, now why did we made that decision... I think we decided that it's the sort of thing which one person can run once per few months and that will deliver its full value. I can maintain it in -mm and we're happy - no need to add it to mainline. No strong feelings either way really. It does have the downside that the kernel explodes if someone adds unlikely or likely to the vdso code and I need to occasionally hunt down new additions and revert them in that patch. That makes it a bit of a maintenance burden. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline & uninline
On Sat, 23 Feb 2008, Andi Kleen wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > >> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR > > > > This is a surprise. I expect that the -mm-only > > profile-likely-unlikely-macros.patch is the cause of this and mainline > > doesn't have this problem. > > Shouldn't they only have overhead when the respective CONFIG is enabled? I uninlined those with allyesconfig. I'll anyway try later on without a number of debug related CONFIGs. -- i. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline & uninline
Andrew Morton <[EMAIL PROTECTED]> writes: >> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR > > This is a surprise. I expect that the -mm-only > profile-likely-unlikely-macros.patch is the cause of this and mainline > doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? > If true, then this likely/unlikely bloat has probably spread into a lot of > your other results and it all should be redone against mainline, sorry :( > > (I'm not aware of anyone having used profile-likely-unlikely-macros.patch > in quite some time. That's unfortunate because it has turned up some > fairly flagrant code deoptimisations) Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline & uninline
On Sat, 23 Feb 2008, Andrew Morton wrote: > On Wed, 20 Feb 2008 15:47:10 +0200 "Ilpo J__rvinen" <[EMAIL PROTECTED]> wrote: > > > -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR > > This is a surprise. It surprised me as well, there were something like 10 bytes I just couldn't explain in IS_ERR size (kernel/uninlined.c: IS_ERR | +25). I was to look into it deeper but didn't have the .o's at hand right away, not so trivial to store results of 5000+ build results except some carefully picked textual output :-)... Hmm, I'll add logging for the disassembly of the uninlined stuff into the next run, that won't cost too much... > I expect that the -mm-only > profile-likely-unlikely-macros.patch is the cause of this and mainline > doesn't have this problem. Ahaa, this explain it, I suspected that there was something (un)likely related elsewhere as well, no wonder why I couldn't reproduce the 25 bytes result in my quick copy-pasted non-kernel test... > If true, then this likely/unlikely bloat has probably spread into a lot of > your other results and it all should be redone against mainline, sorry :( It isn't that troublesome to redo them, it's mainly automatic combined with impatient waiting from my behalf :-)... The spreading problem is probably true, to some extent. I did some runs also with carefully selected CONFIG.*DEBUG.* off under include/net/ earlier, in general it made very little difference, if something bloats, it usually does that regardless of .config. There are probably couple of exceptions when the size is on the boundary where it's very close of being useful to uninline it. One interesting thing in there was that the largest offenders are quite small per call-site but due to vast number of them even a small benefit buys off a lot in kernel wide results. I suspect the differences due to (un)likely will be negligle, because the IS_ERR with all its trivialness is now mostly -15, so anything clearly larger than that will likely still be a win x n (where n is quite large). Anyway, I'll see when I get the new set of tests running... :-) I'd prefer with CONFIG.*DEBUG off to get larger picture about non-debug builds too (especially the scatterlist.h things interest me a lot), do you think that would do as well? Thanks for your comments, I found them very useful. -- i. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline & uninline
On Wed, 20 Feb 2008 15:47:10 +0200 "Ilpo J__rvinen" <[EMAIL PROTECTED]> wrote: > Ok, here's the top of the list (1+ bytes): This is good stuff - thanks. > -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline uninline
On Wed, 20 Feb 2008 15:47:10 +0200 Ilpo J__rvinen [EMAIL PROTECTED] wrote: Ok, here's the top of the list (1+ bytes): This is good stuff - thanks. -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline uninline
On Sat, 23 Feb 2008, Andrew Morton wrote: On Wed, 20 Feb 2008 15:47:10 +0200 Ilpo J__rvinen [EMAIL PROTECTED] wrote: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. It surprised me as well, there were something like 10 bytes I just couldn't explain in IS_ERR size (kernel/uninlined.c: IS_ERR | +25). I was to look into it deeper but didn't have the .o's at hand right away, not so trivial to store results of 5000+ build results except some carefully picked textual output :-)... Hmm, I'll add logging for the disassembly of the uninlined stuff into the next run, that won't cost too much... I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Ahaa, this explain it, I suspected that there was something (un)likely related elsewhere as well, no wonder why I couldn't reproduce the 25 bytes result in my quick copy-pasted non-kernel test... If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( It isn't that troublesome to redo them, it's mainly automatic combined with impatient waiting from my behalf :-)... The spreading problem is probably true, to some extent. I did some runs also with carefully selected CONFIG.*DEBUG.* off under include/net/ earlier, in general it made very little difference, if something bloats, it usually does that regardless of .config. There are probably couple of exceptions when the size is on the boundary where it's very close of being useful to uninline it. One interesting thing in there was that the largest offenders are quite small per call-site but due to vast number of them even a small benefit buys off a lot in kernel wide results. I suspect the differences due to (un)likely will be negligle, because the IS_ERR with all its trivialness is now mostly -15, so anything clearly larger than that will likely still be a win x n (where n is quite large). Anyway, I'll see when I get the new set of tests running... :-) I'd prefer with CONFIG.*DEBUG off to get larger picture about non-debug builds too (especially the scatterlist.h things interest me a lot), do you think that would do as well? Thanks for your comments, I found them very useful. -- i. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline uninline
Andrew Morton [EMAIL PROTECTED] writes: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline uninline
On Sat, 23 Feb 2008, Andi Kleen wrote: Andrew Morton [EMAIL PROTECTED] writes: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? I uninlined those with allyesconfig. I'll anyway try later on without a number of debug related CONFIGs. -- i. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline uninline
On Sat, 23 Feb 2008 14:15:06 +0100 Andi Kleen [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] writes: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? yup. If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. ummm, now why did we made that decision... I think we decided that it's the sort of thing which one person can run once per few months and that will deliver its full value. I can maintain it in -mm and we're happy - no need to add it to mainline. No strong feelings either way really. It does have the downside that the kernel explodes if someone adds unlikely or likely to the vdso code and I need to occasionally hunt down new additions and revert them in that patch. That makes it a bit of a maintenance burden. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 0/8]: uninline uninline
Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. ummm, now why did we made that decision... I think we decided that it's the sort of thing which one person can run once per few months and that will deliver its full value. I can maintain it in -mm and we're happy - no need to add it to mainline. No strong feelings either way really. Apparently nobody has been doing it for a while. :-) Last time I did it it was around the submission time and I actually patched it into mainline kernel to do so. Not particularly hard to do, but sitting in mm-only does make it a bit harder, and there are the vdso problem you just mentioned that one has to fix for himself if it exists in mainline. It does have the downside that the kernel explodes if someone adds unlikely or likely to the vdso code and I need to occasionally hunt down new additions and revert them in that patch. That makes it a bit of a maintenance burden. Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Hua -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8]: uninline uninline
Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Sure it would be possible to define a IN_VDSO symbol in all vdso related files and then do that. Might be useful for other things too. vdso has some very specific requirements. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
