Messages in this thread | | | Date | Sat, 31 Jul 1999 17:34:32 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 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/
| |