lkml.org 
[lkml]   [2000]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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