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.
Just a simple comment:
I use to play with lists and queues in the softwares I design an write at
work. There are also some in the ncr drivers, but this is just anaecdotal.
One of the rule I use to apply to such kind of stuff is to avoid having
instances that are not in any list. Then, most operations are just moves
from one list to another. On the other hand it is far more safe if the
software makes something wrong. You have obviously to remove all links,
when you free an instance, but this probably does not apply to pages of
the page map :).
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).
It is just some general comment, and I may have missed something important
in your patch.
Regards,
Gérard.
On Sat, 27 Mar 1999, Gerard Roudier wrote:
> Andrea,
>
> On Sat, 27 Mar 1999, Andrea Arcangeli wrote:
>
> [ ... ]
>
> > Note that in ftp://e-mind.com/pub/linux/andrea-tree/2.2.4_andrea3.bz2 I am
> > just freeing pages in shrink_mmap() in perfect lru basis (taking care also
> > of buffer aging). But I am doing it at the pagemap level. I see it far
> > more clean and general. I am touching the buffer not in bread but in
> > get_hash_table and in getblk if the buffer is not found in the hash table.
> >
> > Performances are impressive here. I can checkin a whole linux CVS tree in
> > 2sec. Having a perfect lru rocks.
>
> I didn't try your shrink_mmap enhancement for the moment, but just reading
> you, it looks great. I will have a look at it and give it a try when I
> will have time for, may-be to-morrow, and let you know if I have some
> comments.
>
> By the way, it seems that there are some other O/Ses that still use the
> clock algorithm and donnot perform that bad. Anyway, just thinking of
> system with large amount of memory really used disqualified the clock
> algorithm against a simple LRU, in my opinion.
>
> 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/