Re: How to fix the total size of buffer caches in 2.4.5?

[Shansi Ren <sren@CS.WM.EDU>]

>> Also, 2.4.x is relatively deeply frozen. I won't consult Marcelo (he
>> has enough to deal with), but IMHO it's not productive to demonstrate
>> major design changes against a codebase that can (by definition) never
>> absorb them. i.e. it'd be best to try to work against current 2.5.x.
>
> On this point, I disagree.  Given Shansi's goal of ``doing a research
> project'', choosing a stable, documented kernel may be a better idea
> than a developmental kernel.  I may misinterpret the aim of this work,
> but based on the description (comparing a new page replacement
> algorithm against LRU), it seems unlikely that the immediate goal is to
> implement ``major design changes'' that can be aborbed into a
> codebase.  It seems that the intention is simply to use Linux as an
> experimental platform to gather results for page replacment policy
> comparisons.
>
> If I am understanding your situation correctly, Shansi, please let me
> know.  For my projects, I've done some of the groundwork of
> implementing a more ``classical'' global LRU approximation.  It may
> provide you a simpler framework for implementing your own page
> replacement policy.  Since my goal is to obtain experimental results for
> a research project, and not necessarily to produce code that would be
> adopted into the kernel, it may be appropriate for your purposes. My
> work is based on the 2.4.20 kernel, which is close to (and may
> still be) the latest 2.4.x kernel.

  That's exactly what I intend to do. I just want to use Linux as a
platform, and do as little modification to the codebase as possible.
Your help are highly appreciated.




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>