Messages in this thread | | | Date | Mon, 25 Jan 1999 14:14:09 +0100 | From | "Dr. Werner Fink" <> | Subject | Re: MM deadlock [was: Re: arca-vm-8...] |
| |
On Fri, Jan 22, 1999 at 10:29:05AM -0600, Eric W. Biederman wrote: > > WF> At this point the system performance breaks down dramatically even > WF> with 2.2.0pre[567] ... > > If you could demonstrate this it would aid any plea for changing the VM system.
I'm using simple two loops in different kernel trees:
while true; do make clean; make MAKE='make -j10'; done
which leads into load upper 30. You can see a great performance upto load to 25 ... 30+ *and* a brutal break down of that performance at this point. The system is a PentiumII 400MHz with 32, 64, 128MB (mem=xxx) and SCSI only. In comparision to 2.0.36 the performance is *beside of this break down* much better ... that means that only the performance break down at high load is the real problem.
> > WF> What's about a simple aging of program page cluster or better of the > WF> page cache? > > We do age pages. The PG_referenced bit. This scheme as far as I can > tell is more effective at predicting pages we are going to use next > than any we have used before.
What's about a `PG_recently_swapped_in' bit for pages which arn't found anymore with the swap cache? This isn't a prediction but a protection against throwing out the same page in the following cycle.
> > WF> Increasing the age could be done if and only if the pages > WF> or page clusters swapped in and the program wasn't able to use its > WF> time slice. Decreasing the age could be placed in shrink_mmap(). > > People keep playing with ignoring PG_referenced in shrink_mmap for the swap cache, > because it doesn't seem terribly important. If you could demonstrate > this is a problem we can stop ignoring it. > > Eric >
Werner
- 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/
| |