lkml.org 
[lkml]   [1999]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Scheduling latencies news: less RAM = less latency


On Sat, 31 Jul 1999, Ingo Molnar wrote:
>
> On Sat, 31 Jul 1999, Linus Torvalds wrote:
>
> > prune_dcache() I can believe. But the report was about d_lookup(). So
> > somebody is using bad profiling information, and that's dangerous.
>
> sure - d_lookup() is definitely bogus.

Note that I suspect that prune_dcache() being a problem spot is probably
entirely valid, but for all the wrong reasons.

For example, I suspect that you can find "free_inodes()" very high on your
profiles if you start really looking. We have a few bad behaviour corner
cases right now that aren't actually all that hard to trigger: because the
new code (rightly) refuses to free inodes when there are pages associated
with them (2.2.x used to just force-free the pages), the logic to handle
"max_inodes" realy is fairly broken.

That brokenness probably feeds over into prune_dcache(). We try
desperately to free inodes, but we can't because a lot of them have pages
associated with them, and that in turn makes us do bad things with the
dcache too (the inode free logic thinks that the reason the inodes are
locked down is a dcache reference - something that _used_ to be true).

So you end up trying to prune the dcache even when the dcache really
doesn't need to be pruned at all, and in situtations where it might not
actually be a good idea (again, the dcache pruning refuses to prune an
entry with an inode that has active pages...)

I've considered just getting rid of the max_inodes thing. The only reason
it exists is because we currently don't free the inodes due to memory
fragmentation, so we need to artifically cut off the inode supply at some
point. We might want to try just using kmalloc/kfree (or a specialized
slab thing), but I suspect that will waste much more memory than we do
now. It may be worth trying, though.

If you're really doing tests in this area, that's something worth looking
into, I suspect. I bet you'll have a much harder time triggering dcache
problems.

> i agree - I wanted to have something for 2.2 for people to test - i wanted
> to cure symptoms first, we have way too many latency sources right now and
> i first wanted to get something that can be tested. I think that the
> uaccess.h changes are too intrusive as well - i'll rework these things.

Note that the "si_meminfo()" thing really started its life as a debugging
check: verifying that the free pages count actually matched what you got
if you counted the pages by hand.

It was later dis-used from that capacity, as it's not even correct:
si_meminfo gets the wrong results for pages that are part of multi-page
allocations (but we didn't use to support multi-page allocations
originally). But in the meantime it had been hooked into sys_getinfo(),
and thus it stayed on, even though it really is a completely broken piece
of code.

It's really ridiculous. The only thing si_meminfo really gets us is the
number of shared pages, and to calculate that it often uses about 10% of
the CPUtime when you have "xosview" active or something like that. We
could trivially keep track of the number of shared pages on the fly, but
I've been lazy.

But getting rid of some of these problems might be valid on 2.2.x too.

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:53    [W:0.093 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site