Messages in this thread | | | Date | Sat, 27 Mar 1999 19:29:01 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |