Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

From: Joel Schopp (jschopp_at_austin.ibm.com)
Date: 11/01/05

  • Next message: Adrian Bunk: "[2.6 patch] drivers/video/vgastate.c: kill dead code" 
    Date:	Tue, 01 Nov 2005 14:59:06 -0600
To: Nick Piggin <nickpiggin@yahoo.com.au>

    >> The patches have gone through a large number of revisions, have been
    >> heavily tested and reviewed by a few people. The memory footprint of this
    >> approach is smaller than introducing new zones. If the cache footprint,
    >> increased branches and instructions were a problem, I would expect
    >> them to
    >> show up in the aim9 benchmark or the benchmark that ran ghostscript
    >> multiple times on a large file.
    >>
    >
    > I appreciate that a lot of work has gone into them. You must appreciate
    > that they add a reasonable amount of complexity and a non-zero perormance
    > cost to the page allocator.

    The patches do ad a reasonable amount of complexity to the page allocator. In
    my opinion that is the only downside of these patches, even though it is a big
    one. What we need to decide as a community is if there is a less complex way to
    do this, and if there isn't a less complex way then is the benefit worth the
    increased complexity.

    As to the non-zero performance cost, I think hard numbers should carry more
    weight than they have been given in this area. Mel has posted hard numbers that
    say the patches are a wash with respect to performance. I don't see any
    evidence to contradict those results.

    >> The will need high order allocations if we want to provide HugeTLB pages
    >> to userspace on-demand rather than reserving at boot-time. This is a
    >> future problem, but it's one that is not worth tackling until the
    >> fragmentation problem is fixed first.
    >>
    >
    > Sure. In what form, we haven't agreed. I vote zones! :)

    I'd like to hear more details of how zones would be less complex while still
    solving the problem. I just don't get it.
    -
    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/

  • Next message: Adrian Bunk: "[2.6 patch] drivers/video/vgastate.c: kill dead code"

    Relevant Pages

    • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
      ... >> awful lot of complexity to some of these code paths yourself ... ... > then the frag patches can't guarantee anything either. ... an excellent probability of success, that's as good as you're going to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [ 00/10] [Suspend2] Modules support.
      ... On Friday 03 February 2006 21:44, Pavel Machek wrote: ... patches he does not understand. ... and yet you're perfectly happy to add the complexity of sticking half ... showing such a deadlock clearly. ...
      (Linux-Kernel)
    • Re: [PATCH 08/18] V4L/DVB (4734): Tda826x: fix frontend selection for dvb_attach
      ... please do not confuse them. ... My tda10086 and tda826x patches are correct -- there is no question of it. ... Yes, it adds some complexity. ... The gain, however, is to allow having ...
      (Linux-Kernel)
    • Re: [ 00/10] [Suspend2] Modules support.
      ... patches he does not understand. ... Assuming you're refering to the patches that started this thread, ... and yet you're perfectly happy to add the complexity of sticking half ... Complexity in userspace: ungood. ...
      (Linux-Kernel)