Linux-kernel mailing list archive 1997-48,: Re: fork: out of memory

# Re: fork: out of memory

Theodore Y. Ts'o (tytso@MIT.EDU)
Sun, 30 Nov 1997 15:54:17 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Myrdraal: "Re: 2.0.29 is it time to upgrade?"
- Previous message: Mr. James W. Laferriere Network Engineer: "Re: Triton DMA"
- Next in thread: Stephen C. Tweedie: "Re: fork: out of memory"
- Reply: Stephen C. Tweedie: "Re: fork: out of memory"

From: sct@dcs.ed.ac.uk (Stephen C. Tweedie)
Date: 30 Nov 1997 17:09:08 +0000

To get back to all of the VM references to a single page takes more than
just this single page structure, however. We would have to scan the
entire mapping list for the inode owning page, or the appropriate ptes
for any processes owning the page if it is a data page. Fortunately,
the latter could be made a lot easier very simply, just by adding a
single new value to the struct page --- a single data page may be mapped
into multiple processes, but it ought to be at the same virtual address
in each, so having the VA will make it easier to locate the page.

Is that really the case that a page will always be mapped into the same
virtual address? Consider a data file which is mmaped in by various
different processes; there is no guarantee that that they will all be
mapped into the same place.

For the case of text and data pages, though, it would be useful if we
could we did add the virtual address location into the struct page for
this common case. For the case of arbitrary mmap's, it would seem to me
that we could make life much easier by having a circularly linked list
of a structure which described all of the processes and virtual memory
locations that a particular page was mapped in. This would avoid having
to scan the entire inode mapping list or process page tables just to
determine where a particular page was mapped in.

Does this make sense?

- Ted

- Next message: Myrdraal: "Re: 2.0.29 is it time to upgrade?"
- Previous message: Mr. James W. Laferriere Network Engineer: "Re: Triton DMA"
- Next in thread: Stephen C. Tweedie: "Re: fork: out of memory"
- Reply: Stephen C. Tweedie: "Re: fork: out of memory"