lkml.org 
[lkml]   [2000]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Elevator problems began at... 2.3.FORTY-THREE-pre7 to be exact
Date
> 
>
>
> 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[].

Kanoj

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

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.255 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site