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