Messages in this thread | | | Date | Wed, 22 Mar 2000 11:26:10 +0100 (CET) | From | Marco Colombo <> | Subject | Re: Overcommitable memory?? |
| |
On Tue, 21 Mar 2000, James Sutherland wrote:
> >We are not short of memory. We're short of swap. paging-out is the problem, > >not paging-in. > > Where did you get that idea? This situation is "out of RAM+swap". No > RAM free, no swap free, nothing can be allocated. Nothing to do with > paging, either - you can shuffle the memory around fine, the problem > is just that there isn't enough to go round.
We're saying the same thing: being out of swap implies being out of RAM. If you're not out of RAM, the swap area is *empty*. On a Linux system the swap space is almost never empty (unless it's 0-sized, of course) because the kerner thinks it's a better idea to page-out some unused pages to make room for more buffers/cache.
But paging is not "shuffle the memory around": you go either RAM -> disk or disk -> RAM. In OOS situation, if a free page-frame is needed (because of a page fault wants to do a "disk -> RAM" operation), AND none is available (so it's OOM, after all), you first need to do a "RAM -> disk", which is impossible because swap is full. The problem occurs during page-out.
> >> IMO, it's much better to get a signal which means "we're getting short > >> of memory, folks", which can be handled in ONE place, rather than > >> returning 0 as a pointer - which many apps then try to dereference, > >> ending up segfaulting themselves anyway. > > > >"many apps" do not check malloc() return values? I don't call them apps, > >I call them first time students exercises. B-) > >They're are not able to check malloc() return value but they can setup a > >signal handler that triggers runtime a GC() clever enough not to page > >fault itself? I don't follow you. > > If they don't bother handling errors of either sort, they just get > terminated with a signal anyway. If they are careful enough to check > malloc() every time, they would handle SIGBUS as well.
So it doesn't make real difference. Everybody is used to write it's own safe malloc() wrapper. The problem is: you accessed some page of yours, and faulted. The kernel needs to page-in your data. To do that it needs a free page-frame (RAM). There's none. So it looks for an used page-frame that can be paged-out. It selects one. When it tries to page it out, it fails, 'cause swap is full. It kills a signal to you process. How can you be sure that your signal handler it there, *in RAM*, and won't page fault itself? Expecially if it runs some kind of garbage collector (which is likely to touch most of your data pages)? The whole problem arose not at malloc() time, but later when you're accessing your address space. A page that has been previously allocated to you (in RAM) when you wrote it, and later (you not being notified) paged-out to swap.
> > > James. >
.TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it
- 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/
| |