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

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

[Shansi Ren]

Hi folks,

   I'm trying to implement the pure LRU algorithm and a new page 
replacement algorithm on top of 2.4.5 kernel, and compare their 
performance. Can anybody tell me if there is an easy way to seperate the 
buffer cache management from the virtual memory management? And how to 
preallocate a chunk of memory for buffer cache usage exclusively, say, 
32M exclusively for buffer cache?  Thanks.

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

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

[William Lee Irwin III]

On Wed, Jun 11, 2003 at 12:13:34PM -0400, Shansi Ren wrote:
>    I'm trying to implement the pure LRU algorithm and a new page 
> replacement algorithm on top of 2.4.5 kernel, and compare their 
> performance. Can anybody tell me if there is an easy way to seperate the 
> buffer cache management from the virtual memory management? And how to 
> preallocate a chunk of memory for buffer cache usage exclusively, say, 
> 32M exclusively for buffer cache?  Thanks.

What kernel version did you really mean? 2.4.5 sounds implausible to be
what you're really working against.


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

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

[Shansi Ren]

What version do you suggest then? The reason why I choose 2.4.5 is that 
I'm doing a research project. Experiments on earlier versions may not be 
persuasive to audience.


On Wed, 11 Jun 2003, William Lee Irwin III wrote:

> On Wed, Jun 11, 2003 at 12:13:34PM -0400, Shansi Ren wrote:
> >    I'm trying to implement the pure LRU algorithm and a new page 
> > replacement algorithm on top of 2.4.5 kernel, and compare their 
> > performance. Can anybody tell me if there is an easy way to seperate the 
> > buffer cache management from the virtual memory management? And how to 
> > preallocate a chunk of memory for buffer cache usage exclusively, say, 
> > 32M exclusively for buffer cache?  Thanks.
> 
> What kernel version did you really mean? 2.4.5 sounds implausible to be
> what you're really working against.
> 
> 
> -- wli
> --
> 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>
> 

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

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

[William Lee Irwin III]

On Wed, Jun 11, 2003 at 12:28:18PM -0400, Shansi Ren wrote:
> What version do you suggest then? The reason why I choose 2.4.5 is that 
> I'm doing a research project. Experiments on earlier versions may not be 
> persuasive to audience.

That's actually too old, not too new.

You do realize that the 3rd number in the point releases is a
patchlevel, and does not indicate major kernel-wide changes? i.e. if
you're going to hack on 2.4.x, the highest value of x indicates the
version with the most bugfixes. 2.4.y vs. 2.4.x with y > x does not
indicate a brand new major kernel version with oodles of new features,
major subsystems redesigned, and so on.

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.

I myself am brewing up something that appears to be suffering from bad
timing wrt. the release cycle. The way I'm going to handle that is just
keeping it current until the next development cycle opens. This is not
painless (in fact, it is "very painful").


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

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

[Scott F. H. Kaplan]

On Wed, Jun 11, 2003 at 09:50:17AM -0700, William Lee Irwin III wrote:
> On Wed, Jun 11, 2003 at 12:28:18PM -0400, Shansi Ren wrote:
> > What version do you suggest then? The reason why I choose 2.4.5 is that 
> > I'm doing a research project. Experiments on earlier versions may not be 
> > persuasive to audience.
> 
> That's actually too old, not too new.

On this point, I definitely agree.

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

If I am completely off the mark, then forgive me!

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

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

[William Lee Irwin III]

On Wed, Jun 11, 2003 at 11:36:26PM -0400, Scott F. H. Kaplan wrote:
> 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.

This was in no small part a reaction to the backportmania and
proliferation of grossly inappropriate patches against the stable
series of the past several years. IMHO, it is a justified one.

If the goals are truly limited to using 2.4.x as a pure research
vehicle, I say there are no holds barred. But experience is the mother
of pessimism, and I'd rather keep it on the pill than see another
litter of 2.4.x-based core subsystem rewrites or "dev trees" hatched.


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

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

[Shansi Ren]

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