Messages in this thread | | | From | (Kanoj Sarcar) | Subject | Re: Elevator problems began at... 2.3.FORTY-THREE-pre7 to be exact | Date | Wed, 1 Mar 2000 17:02:45 -0800 (PST) |
| |
> > > > 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/
| |