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/