Benjamin Redelings I wrote:
>Rik, thanks for your reply and the Documentation that you mentioned :)
>The SC_ROUNDROBIN thing does sound interesting. Um, actually I have an
>idea for a fix, besides a clearer description of the problem. Could you
>comment on why it would/wouldn't work slightly? Maybe its too
>complicated in practice?
>
> Neither /proc/sys/vm nor SC_ROUNDROUBIN can fix the problem that I'm
>talking about, I think. I'm thinking about what will happen if you have
>say 20Mb of your 64Mb Physical RAM taken up in cache and the other 44 Mb
>taken up by Netscape, XFree86, emacs and other programs. Then you
>attempt to load some large program like (say) quake, which want (say)
>10Mb.
> The question here is not really about the swapping section of VM, but
>about the cache section, right? The question is "How much of the cache
>space is the cache manager going to give up?". There should probably be
With current implementation of shrink_mmap/try_to_free_page question isn't
"How much of the cache space....?", but "What is gonna be given up?".
It might be unused dentries, cache page, or shared zero-filled page, or
just dirty process page. Note, "given up" doesn't mean that page will
actually be freed. It only means its reference count will be decreased.
And if page has more than 0 or 1 (for page cache) references it won't be
freed. With bsdish pmap system in linux we could free page[s] very fast
and could solve memory fragmentation problem, but would also loose about
16*x (where x - total rss in pages) bytes of memory for pmaps.
>a minimum percentage of RAM that is used up by the cache, but the
>maximum SHOULD be near 75% of 64Mb and so will not make any difference
>here. There must be some other principle (that BTW is not in
>/proc/sys/vm now, I think) which decides how much of the cache to give
>up. I suppose you could run some daemon which continuously adjusted the
>values on /proc/sys/vm according to the system weather...but which
>strategy to use?
> Whatever strategy you use SHOULD take into account how much stuff
>kswapd would be forced to swap if the strategy kept back x Mb of RAM for
>cache. This strategy seems like it will have to be complicated to
>work... but I think it would be worth it. It will have to handle 2 easy
>questions, and 1 hard one:
>
>(easy: what I get mad at the machine for not doing ;)
>Q1. If there is not "pressure" for memory, should I let the cache grow
>as large as possible?
>A1. Yes, Duh! e.g., If netscape is the only program (besides XFree)
>running, let the cache get HUGE!
>
>Q2. When other programs start running, should I decrease the cache size,
>or swap?
>A2. Decrease the cache size!!!!
Again, we can't _just_ decrease active cache size (we can decrease memory
taken by unused dentries).
>
>
>(hard)
>Q3. Eventually, we should stop decreasing the cache size, and swap a
>little.
>When?
Never for now.
>
>A3.1 Default (not very good): at some specified "minimum percentage"
>A3.2 Above the "minimum percentage" and depend on the system "weather"
>and other conditions, like various other subsystems. Estimate how the
>improvement of each system ("filesystems" and "memory") would change if
>you gave it 4kb.
> filesystems: performance improves if info is already in memory (cache)
> (virtual) memory: performance improves if info is already in memory
>(e.g. NOT SWAPPED!)
>
>(Note: "pressure" is a good analogy. If you want to minimize the
>"energy" of the system, then the "pressure" should be like "dE/dx". In
>my example, dx=4k. Coming up with some common measure of E could be
>hard... but I would just suggest the total number of disk reads
>predicted by the page-aging statistics.... if that would work.)
>
>That was fun :)
>Any content?
>
>Thanks,
>- -BenRI
Sorry for my _dumb_ <g> english, but it's my second language :-))
Wbr,
sparky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu