[PATCH *] vhand-2.1.65b released

[PATCH *] vhand-2.1.65b released

[Rik van Riel]

Hi there,

since so many people have found something wrong with vhand-2.1.6[45]
(particularly the CPU usage), I have implemented their ideas and
I've made the 'anti-fragmentation' unit even more agressive, since
some people still reported crashes because of memory fragmentation...

You can get the patch at:
<a href="www.fys.ruu.nl/~riel/">my homepage</a>.

happy hacking,

Rik.

----------
Send Linux memory-management wishes to me: I'm currently looking
for something to hack...

Re: [PATCH *] vhand-2.1.65b released

[Mathieu Guillaume]

On Thu, 20 Nov 1997, Rik van Riel wrote:
> since so many people have found something wrong with vhand-2.1.6[45]
> (particularly the CPU usage), I have implemented their ideas and
> I've made the 'anti-fragmentation' unit even more agressive, since
> some people still reported crashes because of memory fragmentation...

After my first tests (intensive use of tin+leafnode, which never failed to
freeze everything since 2.1.something), I can say I like the memory
management much better :)
SysReq reports 0 failed network buffer allocs, whereas I saw more than 20
millions without the patch.
I believe I saw some slowdowns sometimes, but I'm not sure if they're due
to vhand or if they would have happened anyway.
Anyway, I'm much happier with some slowdowns than with some complete
freezes.

Nice work !

					Mat

Re: [PATCH *] vhand-2.1.65b released

[Rik van Riel]

On Thu, 20 Nov 1997, Joe Fouche wrote:

> You wrote
> > since so many people have found something wrong with vhand-2.1.6[45]
> > (particularly the CPU usage), I have implemented their ideas and
> > I've made the 'anti-fragmentation' unit even more agressive, since
> > some people still reported crashes because of memory fragmentation...
> 
> This one (65b) is really good. I also found that I could decrease the numbers
> in /proc/sys/vm/freepages (I had them set kind of high) to improve all-around 
> interactive performance.

All-round performance is improved, but mostly on small-memory
machines... We still need to do some tuning and optimization
for special cases of memory usage (linear, directory scanning,
etc..).
> 
> root         3  0.0  0.0     0     0  ?  SW< 11:34   0:00 (kswapd)
> root         4  1.0  0.0     0     0  ?  SW  11:34   2:16 (vhand)    
See, the CPU usage is way to high. It might be OK for a 32Meg
system, but imagine someone trying this on a 512Meg system :)
Actually, someone with a 512Meg system agreed to try my patch
this weekend.  If things go well the patch might be ready for
integration in the mainstream kernel...

> A good way to test vhand, then, might be to make freepages really high and watch
> as things get swapped out. :)
More importantly, does the system remain stable with an ultra-low
value of freepages?
> 
> Wonder if the kernel could tune freepages automatically, based on some measure
> of the performance of swap devices? Maybe the same thing would apply to some of
> the numbers in struct swap_control_v5? 

But of course it could. Setting the value of min_free_pages to the
average nr of pagefaults we had during the last time (weighed after
time...) could result in a smaller number of freepages when we don't
need them, and increase the number of freepages when we need the
memory most. Hmm, I gotta try this one.
> 
> Anyway, send it to Linus, it works great! :)

It works great for US, small-memory users. But there are also
those people around who have large (> 64M) memory systems.  I
won't send it to Linus unless I know it works _flawlessly_ on
large-memory systems as well.

Rik.

----------
Send Linux memory-management wishes to me: I'm currently looking
for something to hack...