Re: 2.1.91 swap performance: jerky.

Stephen C. Tweedie (sct@dcs.ed.ac.uk)
Sun, 5 Apr 1998 16:15:55 +0100


Hi,

On Wed, 1 Apr 1998 20:37:08 -0800 (PST), Linus Torvalds <torvalds@transmeta.com> said:

> On Sat, 28 Mar 1998, Itai Nahshon wrote:
>> Suppose a page was swapped out, but the physical memory that it occupied
>> was not used for something else. Now the process page-faults in that
>> address. Can the page be reclaimed from memory (the data is still
>> in the main memory?) or do we need to page-in from disk?

> We will currently page-in. What you're asking for is essentially the
> reverse of the swap cache, and yes, we'll probably do it some day (Stephen
> Tweedie and some others have been working on this).

In fact, I've got it working on a test box --- it's just not stable yet.
I have a 6 MB machine sitting with about 100K of free memory and over a
megabyte of swapped out, but still cached, pages. I can get free memory
down to only a few pages and it still works --- the swapped pages can be
recovered even from within an interrupt. When it works, it works very
well indeed. When it breaks, it gets very very messy, but I'm working
on it...

> The main problem as far as I see is that while the pages can be quickly
> free'd when required, the fragmentation worries me. It needs to be
> integrated with the buddy system somehow (ie it should coalesce using the
> buddy system, but we could then re-extract the page when required. Or
> something).

Absolutely, this is the main concern. The way it currently works is a
bit like the mainstream kernel --- the buddy allocater just keeps
blindly stealing pages off the not-quite-free swap cache page list and
adding them to the true free pool until a big enough buddy page opens
up. The difference is that we now do this reactively, only stealing
enough pages to satisfy the allocation request when it arrives rather
than proactively scourging lots of memory just in case a large memory
request comes in.

--Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu