Messages in this thread | | | Date | Fri, 7 Jul 2000 18:58:41 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [linux-audio-dev] Re: [PATCH really] latency improvements, one reschedule moved |
| |
On Sat, 8 Jul 2000, Roger Larsson wrote: > > I examined the patches again and the fact that it runs > do_try_to_free_pages > periodically may improve performance due to its page cleaning effect - > all pages won't be dirty at the same time...
One potential problem with this, though, is that it keeps shrinking the dcache etc: even though various parts of the system refuse to touch pages once the machine has "enough" memory, the periodic wake-up will cause those caches that don't have the "I don't need to do this" logic to potentially be starved.
The keep_kswapd_awake() logic protects from the worst case (it won't go on forever), but I wonder if it might still not cause bad behaviour when one zone is getting balanced and the other zones shouldn't be touched, but the continual trickle will cause the dcache etc stuff to be free'd with very little good reason.
The "one zone gets rebalanced" is normal behaviour, so this is why I worry about the dcache.
> But it has a downside too - it will destroy the LRU order of pages... > PG_referenced loses some of its meaning...
That part doesn't bother me in the least - it can be seen as a simple aging of the referenced bit. Especially if we're going to re-introduce the multi-bit page "age" code, aging the reference bits actually only improves stuff.
The fact that shrink_mmap() gets called regularly also makes bdflush potentially less important, because shrink_mmap() actually does a better job of flushing dirty data anyway these days, and in many ways it makes sense to have this kind of background LRU list activity.
Linus
- 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/
| |