On Thu, 13 Jan 2000, Kanoj Sarcar wrote:
> No, I am referring to a different problem that I mentioned in the
> doc. If you have a large number of free regular pages, and the dma
> zone is completely exhausted, the 2.2 decision of balacing the dma
> zone might never fetch an "yes" answer, because it is based on total
> number of free pages, not also the per zone free pages. Right? Things
> will get worse the more non-dma pages there are.
Kanoj, you're wrong. 2.2 works quite well because of the fact that the
low memory mark will tend to consist almost entirely of DMAable pages.
The only allocations that regularly eat into them on a loaded machine are
interrupts, which tend to be short term allocations anyways. But as soon
as DMAable memory is freed, it tends not to be allocated until interrupts
consume all memory again.
> Oh, okay I see. There is nothing about the dma zone then, you could
> make the balancing more aggressive for the other zones too. Basically,
> these kinds of tuning should be controlled by sysctls (instead of
> >>7, do >> N), so while most sites will prefer to run with the least
> aggressive balancing, there may be sites with drivers that need
> many high-order pages, they would be willing to sacrifice some
> performance by doing more aggressive balancing. Comes under finetuning
> in the doc.
Whoa, hold on here. Last time we tried to do more aggresive balancing, it
was a complete and total disaster that resulted in completely random swap
storms, resulting in spectacularly unusable systems on the lower end
(iirc 64mb was around the breakeven point). Before harder limits are
placed on memory types and orders, the behaviour of both kswapd and the
allocator need to be tweaked. so put in the mechanism, but don't start
enforcing it too aggresively.
-ben
-
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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:24 EST