[lkml]   [2001]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: need help interpreting 'free' output.

On Tue, 30 Oct 2001, Andrea Arcangeli wrote:
> It is still interesting to hear if it makes a big performance differece
> under swap though. In particular it would be very nice to keep inodes
> with pagecache in it out of the unused-inode-list, but it would need
> additional bitkeeping in inode.c.

Yes. I'm worried about the fact that icache shrinking was one of the top
CPU users under heavy swapout, so I'd like to do _something_. The LRU
approach is probably the cleanest and least random approach.

> I'm also wondering why you dropped the early-cow for the write swapins,
> just to avoid managing the anon pages in the lru in do_swap_page and to
> have the logic only in once place? I kept the early-cow logic so I only
> get 1 page fault for every write-swapped-in pages.

I only dropped it because the locking rules for how exclusive swap pages
work were too unclear, and I wanted to have the "remove on write" in just
one place.

Then I cleaned up the logic and made the thing use the pagecache lock
properly and turned it into "remove_exclusive_swap_page()", and now I'm
not worried about it any more, so I'm considering moving it back again.

HOWEVER, _then_ I started wondering about whether the thing needs to be
removed from the swap cache at all, and came to the conclusion that for
the only case we really care about (and the only case where we _can_
re-use the swap cache page), we don't actually need to remove it from the
cache in the first place.

I think we should just share the page, and make the WP (and early-COW in
do_swap_page()) logic just be

/* Are we now the only user? */
if (swap_count(page) == 1 && page_count(page) == 2) {
pte = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot))

There's no real reason to remove the page from the swap cache - that only
means that we have to wait for the page to unlock (because you need to
lock the page in order to remove the buffers that you need to remove
_before_ you free the swap entry) and other crap that has no real point to

When we fork() and possibly share the page non-exclusively, we will
_already_ mark the page read-only and do the COW - so after that point we
will correctly just copy the page on demand.

Much simpler, I think.

Does anybody see why we have to remove it from the swap cache at all?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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