lkml.org 
[lkml]   [1998]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.090 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site