Messages in this thread | | | Date | Sat, 27 Mar 1999 21:05:55 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: buffer cache behavior on memory-constrained systems (fwd) |
| |
On Sat, 27 Mar 1999, Andrea Arcangeli wrote:
> 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.
Hmmm... I donnot doubt all is clear in your mind, but the reality with large software is that they may be modified by numerous guys, and including some considerations on robustness in the design and implementation is a good thing in my opinion.
> 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.
Indeed it does not, but a simple bug that queues something that is already queued will break everything. The problem with bugs for users is their actual effect, the opinion of expert programmers that usually excuse themselves by claiming that every software has bugs is quite irrelevant in this regard (this applies also to me ;) ).
Note that for the ncr drivers, I donnot expect much people to hack them, and I donnot apply completely the above recommendations, btw. ;-) But, the upper layers of the kernel seems to have a lot more candidates that hack the same modules.
> Gerard, really many thanks for reading my code and for commenting it!
No thanks needed. There are some points on which we seem to disagreed ;-), just way of life, and flames seem to be the usual consequence of the media we are using for discussions. By the way, despite all the fire spat in the threads, I haven't changed my mind about the argued topics. :-)
Your page LRU change is something I would have been able or courageous enough to implement and I will give it a try. Thanks for having implemented it.
Gérard.
- 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/
| |