[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.0703151532530.29483@cpu102.cs.uwaterloo.ca>
Date: Thu, 15 Mar 2007 15:55:08 -0400 (EDT)
From: Ashif Harji <asharji@...uwaterloo.ca>
To: Nick Piggin <npiggin@...e.de>
cc: Chuck Ebbert <cebbert@...hat.com>, linux-mm@...ck.org,
Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH] mm/filemap.c: unconditionally call mark_page_accessed
On Thu, 15 Mar 2007, Nick Piggin wrote:
> On Thu, Mar 15, 2007 at 11:56:59AM -0400, Chuck Ebbert wrote:
>> Ashif Harji wrote:
>>>
>>> This patch unconditionally calls mark_page_accessed to prevent pages,
>>> especially for small files, from being evicted from the page cache
>>> despite frequent access.
>>>
>>> Signed-off-by: Ashif Harji <asharji@...a.uwaterloo.ca>
>>>
>>
>> I like mine better -- it leaves the comment:
>
> How about this? It also doesn't break the use-once heuristic.
>
> --
> A change to make database style random read() workloads perform better, by
> calling mark_page_accessed for some non-page-aligned reads broke the case of
> < PAGE_CACHE_SIZE files, which will not get their prev_index moved past the
> first page.
>
> Combine both heuristics for marking the page accessed.
>
> Signed-off-by: Nick Piggin <npiggin@...e.de>
>
> Index: linux-2.6/mm/filemap.c
> ===================================================================
> --- linux-2.6.orig/mm/filemap.c
> +++ linux-2.6/mm/filemap.c
> @@ -929,7 +929,7 @@ page_ok:
> * When (part of) the same page is read multiple times
> * in succession, only mark it as accessed the first time.
> */
> - if (prev_index != index)
> + if (prev_index != index || !offset)
> mark_page_accessed(page);
> prev_index = index;
>
>
It sounds like people are happy with the fix suggested by Nick. That fix
is okay with me as it fixes the problem I am having.
I suspect, however, that by not directly detecting the problematic access
pattern, where the file is accessed sequentially in small hunks, other
applications may experience performance problems related to caching. For
example, if an application frequently and non-sequentially reads from the
same page. This is especially true for files of size < PAGE_CACHE_SIZE.
But, I'm not sure if such an access pattern likely.
ashif.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists