Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Wed, 14 Apr 1999 00:23:29 +0100 (BST) | Subject | Re: [patch] fix for cc1 Out of memory [Re: [TESTCASE] `Out of memory for cc1'] |
| |
Hi,
On Mon, 12 Apr 1999 14:54:27 -0700 (PDT), Linus Torvalds <torvalds@transmeta.com> said:
> I was looking at the shared memory code, and just basically I cannot > convince myself that it can be reliable. It has all these hacky things in > it to bypass the normal mm layer logic, and I would not be at all > surprised if it has serious problems when swapping. Whether this could > explain any problems or not is unclear, but it does need to be cleaned up: > at least enough that I can convince myself that it could possibly work..
> Didn't somebody (Andrea?) have a good test-program for shared memory under > low memory?
I did, and no amount of stressing was able to show up any shm fault under heavy swapping. However, one thing it did _not_ test was heavy mapping and unmapping of shm segments, which is what appears to be the problem here.
Interestingly, the reason I did that testing was for an application which was seeing corrupt data in low mem on 2.0 but not on 2.1. This was before the AVL code went back into 2.1, so it may in fact have been another instance of this latest problem.
> Andrea, Stephen, any comments/interest?
> This should be further fixed to use the page cache etc etc (and remove the > "attach" list that shouldn't be needed any more and other cleanups). > Consider this a weak first step.
Yep. Having a separate shm swapout loop is also inherently bad for VM balancing: eventually we should probably just lose that and use the same sort of test we use in the normal mmap() case, writing to swap on the last deaccess but keeping the link between swap and core via the swap cache. That is currently impractical for the same reason that shared anon maps are tricky: the swap cache assumes that all references are readonly. It's not that hard a change, but it is far too dangerous an update for 2.2.
--Stephen
- 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/
| |