Messages in this thread | | | Date | Sun, 29 Mar 1998 15:14:11 +0200 (CEST) | From | MOLNAR Ingo <> | Subject | Re: 2.1.91 swap performance: jerky. |
| |
On Sat, 28 Mar 1998, Linus Torvalds wrote:
> > Without some very smart algorithm that selects pages to swap out, this > > 128kB contiguous free area goal seems to me close to impossible without > > trashing LOTS of really used pages. > > No, it seems to be a very good goal, actually. I've had reports of this > approach getting close to exact the behaviour we want: we don't actually > want exactly 128kB free, we want something like 5-10% of memory free just > in case...
one big problem with freeing memory is the need of accessing VM stuff and sleeping, which should really not be done from IRQ handlers.
I have looked through previous discussions, but i have not found much analysis about the following approach: 'half-freeing' certain pages, ie. removing them from VM mappings _but_ still keeping them around in the page cache. Such pages can still be reused with a cost of a minor page fault (100-200 cycles).
one problem is homogenity, a 128k 'continuous free area' in the page cache is not a single object but possibly an inhomogene set of 32 pages with different inodes and offsets. So we cannot keep them amongst buddy allocator objects.
my point is, the following two policies are almost equivalent, from the 'DMA and other atomic allocations' point of view:
- keep the buddy allocator "prepared"
- keep the 'buddy allocator and the page cache' "prepared"
proposal to inetgrate this into our current allocators, without adding one more layer of caching: we could keep page cache pages in the freelists, by adding one more bit to freelist objects: 'cached' and 'not cached'. If a certain buddy-object is marked 'cached', then we have to cycle through all 'member pages' and remove them from the page cache if cached. The performance point here is that higher-order buddy elements are less used than one-page elements. [we do not need any page-cache side data if we put _every_ 'clean and unused' page cache element into buddy freelists.]
so under the proposed scheme we have to extend RMQUEUE() and EXPAND() to propagate the 'cached' bit properly, and a new branch in __get_free_pages() to possibly un-cache cached pages.
Yes, it has a performance hit, but it's a deep concept i think: '_never_ keep unused memory around'. [ok, destoying an inode invalidates the cache, but it's rare].
and all in one i dont think it even adds more complexity, we just delay the 'remove from the page cache' action a bit, until it's _really_ used. [We could even make it mandatory (thus no extra bit but one extra check per page in gfp()).]
kswapd/bdflush balances based on 'freelist' statistics, just like now. Thus we could have both the baby and the bathwater as well ;)
[i bet i have missed something, it's too simple]
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |