lkml.org 
[lkml]   [2000]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch?] Re: Do ramdisk exec's map direct to buffer cache?
On Mon, 31 Jul 2000, Linus Torvalds wrote:

> Mike, would you mind checking something where mm/filemap.c does _not_ do
> the "try_to_free_buffers()" when GFP_IO isn't set? Instead of
>
> int wait = ((gfp_mask & __GFP_IO) && (nr_dirty-- < 0));
>
> do something like
>
> int wait;
>
> if (!(gfp_mask & __GFP_IO))
> goto unlock_continue;
> wait = nr_dirty-- < 0;

NOOOOOOOOOO!!!!!

I tried this and skipping dirty pages we want to replace
because we "can't do more IO" really messes up page replacement
in a bad, Bad, BAD way...

It causes us to _skip_ the dirty pages we want to free, which
in turn causes us to clear the referenced bit of clean pages
we do NOT want to free just yet. After the second loop over
the "lru" list, we'll start freeing the WRONG pages, leading
to abysmal system performance.

The solution would be to place these pages on a separate
(inactive_dirty?) list and to have each successive shrink_mmap()
start IO on a few of these pages until we either have enough
free pages or until we have no old&dirty pages left.

Something like:

if (zone->free_pages + (zone->id_pages / 2) > zone->pages_high)
goto cache_unlock_continue;

would do the trick here. Especially when we're scheduling
some of those inactive_dirty pages for IO every time and
free the ones where IO finished.

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/ http://www.surriel.com/


-
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/

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