[RFC PATCH 0/8]: uninline & uninline - Kernel

This is a discussion on [RFC PATCH 0/8]: uninline & uninline - Kernel ; Andrew Morton 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: [RFC PATCH 0/8]: uninline & uninline

  1. Re: [RFC PATCH 0/8]: uninline & uninline

    Andrew Morton 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [RFC PATCH 0/8]: uninline & uninline

    On Sat, 23 Feb 2008, Andi Kleen wrote:

    > Andrew Morton 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/

    On Sat, 23 Feb 2008 12:05:36 +0200 (EET) "Ilpo Järvinen" wrote:

    > On Sat, 23 Feb 2008, Andrew Morton wrote:
    >
    > > On Wed, 20 Feb 2008 15:47:18 +0200 "Ilpo Järvinen" wrote:
    > >
    > > > vmlinux.o:
    > > > 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
    > > >
    > > > ...+ these to lib/jhash.o:
    > > > jhash_3words: 112
    > > > jhash2: 276
    > > > jhash: 475
    > > >
    > > > select for networking code might need a more fine-grained approach.

    > >
    > > It should be possible to use a modular jhash.ko. The things which you
    > > have identified as clients of the jhash library are usually loaded as modules.
    > > But in the case where someone does (say) NFSD=y we do need jhash.o linked into
    > > vmlinux also. This is doable in Kconfig but I always forget how.

    >
    > Ok, even though its not that likely that one lives without e.g.
    > net/ipv4/inet_connection_sock.c or net/netlink/af_netlink.c?


    Sure, the number of people who will want CONFIG_JHASH=n is very small.

    > But maybe
    > some guys "really know what they are doing" and can come up with config
    > that would be able to build it as module (for other than proof-of-concept
    > uses I mean)... :-/
    >
    > > Adrian, Sam and Randy are the repositories of knowledge here

    >
    > Thanks, I'll consult them in this. I've never needed to do any Kconfig
    > stuff so far so it's no surprise I have very little clue... :-)


    Thanks. If it gets messy I'd just put lib/jhash.o in obj-y. I assume it's
    pretty small.

    > I've one question for you Andrew, how would you like this kind of
    > cross-subsys toucher to be merged, through you directly I suppose?


    Sure, I can scrounge around for appropriate reviews and acks and can make
    sure that nobody's pending work gets disrupted.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [RFC PATCH 0/8]: uninline & uninline

    On Sat, 23 Feb 2008 14:15:06 +0100 Andi Kleen wrote:

    > Andrew Morton 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. profile-likely patch (was Re: [RFC PATCH 0/8]: uninline & uninline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHxbVHcC3lWbTT17ARAorCAJ9+Kwiev0Rjp6LH/cNpEt8OwfvxUQCeN01q
    hdlaHId12CL/BF7MZ12ZZ2M=
    =VMXP
    -----END PGP SIGNATURE-----


  8. Re: [RFC PATCH 3/8] [NET]: uninline dev_alloc_skb, de-bloats a lot

    On Thu, 21 Feb 2008, Ilpo Järvinen wrote:

    > On Wed, 20 Feb 2008, Jan Engelhardt wrote:
    >
    > > On Feb 20 2008 17:27, Patrick McHardy wrote:
    > >
    > > > __dev_alloc_skb() is also an inline function which performs
    > > > some extra work. Which raises the question - if dev_alloc_skb()

    > >
    > > I'd like to see the results when {__dev_alloc_skb is externed
    > > and dev_alloc_skb remains inlined}.

    >
    > The results are right under your nose already... ;-)
    > See from the list of the series introduction:
    >
    > http://marc.info/?l=linux-netdev&m=120351526210711&w=2
    >
    > IMHO more interesting number (which I currently don't have) is the
    > _remaining_ benefits of uninlining __dev_alloc_skb after
    > dev_alloc_skb was first uninlined.


    I've measured this now... Without many debug CONFIGs (in v2.6.25-rc2-mm1),
    the dev_alloc_skb is much less than 23kB:

    382 funcs, 157 +, 12335 -, diff: -12178 --- dev_alloc_skb
    dev_alloc_skb | +37

    ....and on top of that, I got only this:
    48 funcs, 111 +, 836 -, diff: -725 --- __dev_alloc_skb

    Not that impressive compared with many much worse cases (wasn't a big
    surprise because there were fewer callsites for the latter).

    Anyway, would I uninline it (or one some another function that has such
    two variants that are good candidates for uninlining), should I try to
    avoid deepening the call-chain by two functions? To me it seems that only
    way to fool gcc to do that for sure would be using some trick like this:
    Rename __dev_alloc_skb to ___dev_alloc_skb in the header (with appropriate
    don't ever call this due to bloat comment added) and both __dev_alloc_skb
    and dev_alloc_skb could then be made to call that one in .c file.
    Otherwise I'm not that sure gcc wouldn't try to be too clever if I just
    use inline in .c file.

    --
    i.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2