lkml.org 
[lkml]   [1999]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: buffer cache behavior on memory-constrained systems (fwd)
On Sat, 27 Mar 1999, Gerard Roudier wrote:

>I just have downloaded and looked a few minutes into your page LRU patch
>for shrink_mmap. By the way, it would be fine if you separated it from
>other changes.

I can trivially do that... but for testing people can download all the
stuff (taking uptodate all the stuff in one patch saves me tons of time ;).

>So, my first thought is that you should use 2 lists, and implement your
>primitives as follows:
>
>static inline void lru_add(struct page * page)
>{
>+ list_del(&page->lru);
> list_add(&page->lru, &lru_head);
> nr_lru_pages++;
>}
>
>static inline void lru_del(struct page *page)
>{
> list_del(&page->lru);
>+ list_add(&page->lru, &other_head);
> nr_lru_pages--;
>}
>
>static inline void lru_mkyoung(struct page *page)
>{
> list_del(&page->lru);
> list_add(&page->lru, &lru_head);
>}
>
>You also will have to queue everything in some list at initialisation.
>
>Your will waste some CPU, but it is more safe and will be more flexible,
>IMO, for future improvements (your also can use only 2 primitives for your
>page map LRU).

Currently the only entry points for the lru list are quite clear in my
mind and there's no confusion so currently the safety is not an issue.

And in general I think it's desiderable taking things in a unused_list
when you are able to _recycle_ them. In the pagemap case the recycling
thing make no sense.

Gerard, really many thanks for reading my code and for commenting it!

Andrea Arcangeli


-
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:51    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site