[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Elevator problems began at... 2.3.FORTY-THREE-pre7 to be exact
    > On Thu, 2 Mar 2000, Lawrence Manning wrote:
    > > >
    > > > You meant 2.3.43-6 and 2.3.43-7, right?
    > >
    > > Sorry, yes! The patches between 2.3.42 and 2.3.43! The uname is still
    > > 2.3.42, so I got confused :( oops, sorry for confusion folks!! Won't
    > > happen again :) Its first time I've looked at pre patches...
    > Thanks for hunting it down, though. The 6-7 is one of the bigger jumps,
    > but it does contain a few rather suggestive things.
    > In particular, pre-6-7 is where the per-zone balancing thing went in.. And
    > I think I see something really strange: the "pages_min/low/high" stuff is

    Actually, I think the zone balancing thing first came out in 2.3.41, which
    probably exonerates it from the Elevator problems.

    But look at the explanation for the cumulative numbers below.

    > per-zone, but the zone size requirements are calculated with some really
    > strange calculations based off the _cumulative_ size of the zones as they
    > are added.
    > Kanoj, I think that was your change. Would you mind looking at
    > free_area_init_core()
    > and explaining the logic behind the
    > zone->pages_min = mask;
    > zone->pages_low = mask*2;
    > zone->pages_high = mask*3;
    > calculations (or if no logic to them, which is my suspicion, then maybe
    > come up with a fix ;).
    > Using a cumulative number and it's ratio just can't be right. And getting
    > these numbers wrong will make kswapd try to page out some zone much more
    > aggressively than it should, so it would explain dbench performance going
    > down..
    > Linus

    This is from the file Documentation/vm/balance:

    "In 2.2, memory balancing/page reclamation would kick off only when the
    _total_ number of free pages fell below 1/64 th of total memory. With the
    right ratio of dma and regular memory, it is quite possible that balancing
    would not be done even when the dma zone was completely empty. 2.2 has
    been running production machines of varying memory sizes, and seems to be
    doing fine even with the presence of this problem. In 2.3, due to
    HIGHMEM, this problem is aggravated.

    In 2.3, zone balancing can be done in one of two ways: depending on the
    zone size (and possibly of the size of lower class zones), we can decide
    at init time how many free pages we should aim for while balancing any
    zone. The good part is, while balancing, we do not need to look at sizes
    of lower class zones, the bad part is, we might do too frequent balancing
    due to ignoring possibly lower usage in the lower class zones. Also,
    with a slight change in the allocation routine, it is possible to reduce
    the memclass() macro to be a simple equality.

    Another possible solution is that we balance only when the free memory
    of a zone _and_ all its lower class zones falls below 1/64th of the
    total memory in the zone and its lower class zones. This fixes the 2.2
    balancing problem, and stays as close to 2.2 behavior as possible. Also,
    the balancing algorithm works the same way on the various architectures,
    which have different numbers and types of zones. If we wanted to get
    fancy, we could assign different weights to free pages in different
    zones in the future."

    So, the cumulative logic in free_area_init_core() is simply this:
    when do we consider a zone unbalanced? When the #free pages in a
    class of memory falls below 1/64th of the total #free pages in
    the class.

    Class 0, dma class = ZONE_DMA pages
    Class 1, direct mapped class = ZONE_DMA + ZONE_REGULAR pages
    Class 2, the other class = ZONE_DMA + ZONE_REGULAR + ZONE_HIGHMEM pages

    This is also why we have classfree().

    Of course, this computations and tunings could be refined for better
    performance. We would need to tweak zone_balance_ratio[],
    zone_balance_min[] and zone_balance_max[].


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.024 / U:62.428 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site