Hi!
> > 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?
Because network "ping" packet came?
Because user plugged in 10 more usb mice?
> > 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'.
Which fails if you have just 5 pages total! No matter how much swap
space you have, with 2 memory pages total, nothing can help you and
you are deadlocked. That was my point.
Pavel
-- 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- 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:10 EST