Pavel Machek wrote:
> Take a look at kernel memory allocation... There are kmallocs
> everywhere. 1 page will not help anything.
--- You still haven't answered the question. After startup, why is the kernel allocating memory if not by user or user-proxy (program) request?> > BTW You need 6 pages in worst case on i386 _to make any progress at > all_. (Imagine instruction at page boundary, doing movsd from unaligned > doubleword on two pages to unaligned doubleword on other two pages.) > That means that system with less than 6 pages available to userspace > is dead! > Pavel --- Sigh. Let us pretend that non of the pages of 'said' instruction are in memory. Assume for discussion we keep an ordered list of last used pages with the most recently used at the end of the list. CPU requests address containing first part of movsd instruction. Page is faulted into memory using a 1 page free-buffer algorithm (not that I'm saying that is the optimal performance case, but it is the minimimal case). Assume instruction spans Pages I and I'. Assume Data Source page spans pages DS and DS'. Assume Data Targe page spans pages DT and DT'. After the first fault, our ordered memory list looks like this:
oldest->P1->P2->P3...->I.
The CPU instruction fetcher looks for the next bytes of the instruction. Again, page fault and I' is read in. Now ordered memory looks like:
oldest->P2->P3 ... ->I->I'.
Then the first part of source data gets faulted in:
oldest->P3->P4->P5 ... ->I->I'->SD.
Then first part of destination:
oldest->P4->P5->P6 ... ->I->I'->DS->DT.
Then the 2nd part of the DS, DS':
oldest->P5->P6->P7 ... ->I->I'->DS->DT->DS'.
Finally the 2nd part of the DT, DT':
oldest->P6->P7 ... ->I->I'->DS->DT->DS'->DT'.
Now all parts are in memory and you continue execution -- not "DEAD", just slow.
The situation you describe occurs all the time internally to the X86 processor series.
Depending on the processor you have as little as 8K instruction and 8K data primary caches.
That's only 16K of memory total. That is *continually* "out of memory", but simple handles the 'out of memory case' (no unused cache slots for a given page) as *NORMAL* functionality. It's not only *not fatal*, it is normal -- and the processor continues running along just fine.
Secondary cache sizes vary among the current x86 line from 128K (unified data and instruction) cache on a celeron up to as high as 2M on the Xeon chips. Again...128K or 2M is *WAY* less than the useful address space of most unix systems. And again -- being completely out of cache space is *normal*. Now we move to the in RAM cache as layer slower than L2 cache with the slowest Virtual Memory being on disk. The differences in how memory caches are handled are slightly different in that you have never have data that is "just" in the L1 cache. L1 implies presence in L2 implies presence in L3. It makes for much easier memory handling.
At the kernel level -- it manages it's "RAM" cache and since DISK is *SO* much slower (we're not talking clock-tick level speed differences), we can choose to require a page to exist *only* once in all of VM, treating it as 1 unified memory space -- there is no benefit to requiring a disk-page for every in memory page. There *is* a benefit to having enough space in your VM to map all of your processes -- since if you are overcommitted, then you are right -- you are "dead" -- or at least some process is. When the process asks for the memory you can't "say no" -- since you've already given the process the go-ahead to assume it has the resources it just asked for and can run.
Book suggestion:
UNIX Systems for Modern Architectures: Symmetric Multiprocesssing and Caching for Kernel Programmers by Curt Schimmel
-l
> -- > I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." > Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:08 EST