lkml.org 
[lkml]   [2004]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat
    Nick Piggin wrote:
    > David S. Miller wrote:
    >
    >> On Sun, 05 Sep 2004 15:44:18 +1000
    >> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    >>
    >>
    >>> So my solution? Just teach kswapd and the watermark code about higher
    >>> order allocations in a fairly simple way. If pages_low is (say), 1024KB,
    >>> we now also require 512KB of order-1 and above pages, 256K of order-2
    >>> and up, 128K of order 3, etc. (perhaps we should stop at about order-3?)
    >>
    >>
    >>
    >> Whether to stop at order 3 is indeed an interesting question.
    >>
    >> The reality is that the high-order allocations come mostly from folks
    >> using jumbo 9K MTUs on gigabit and faster technologies. On x86, an
    >> order 2 would cover those packet allocations, but on sparc64 for example
    >> order 1 would be enough, whereas on a 2K PAGE_SIZE system order 3 would
    >> be necessary.
    >>
    >
    > Yeah I see.
    >

    Hmm, and the crowning argument for not stopping at order 3 is that if we
    never use higher order allocations, nothing will care about their watermarks
    anyway. I think I had myself confused when that question in the first place.

    So yeah, stopping at a fixed number isn't required, and as you say it keeps
    things general and special cases minimal.
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.022 / U:0.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site