cache limit

Quoted 5 lines · Ihar 'Philips' Filipau

If I have 1GB of memory and my applications for use only 16MB - it
doesn't mean I want to fill 1GB-16MB with garbage like file my momy had viewed two weeks ago.

That's it: OS should scale for *application* *needs*.

Quoted 3 lines

Can you compare in your mind overhead of managing 1GB of cache with
managing e.g. 16MB of cache?

Ok, let's benchmark it.

Yes, I can see the logic in your argument, but at this point, numbers are needed to see if or how much of a win this might be.

Quoted 4 lines · Mike Fedyk

Ok, let's benchmark it.

Yes, I can see the logic in your argument, but at this point, numbers are needed to see if or how much of a win this might be.

[ I beleive you can see those thread about O_STREAMING patch.
Not-caching was giving 10%-15% peformance boost for gcc on kernel compiles. Isn't that overhead? ]

I will try to produce some benchmarktings tomorrow with different
'mem=%dMB'. I'm afraid to confirm that it will make difference.
But in advance: mantainance of page tables for 1GB and for 128MB of
RAM are going to make a difference.

That was because they wanted the non-streaming files to be left in the cache.

Quoted 4 lines

I will try to produce some benchmarktings tomorrow with different
'mem=%dMB'. I'm afraid to confirm that it will make difference.
But in advance: mantainance of page tables for 1GB and for 128MB of
RAM are going to make a difference.

I'm sorry to say, but you *will* get lower performance if you lower the mem= value below your working set. This will also lower the total amount of memory available for your applications, and force your apps, to swap and balance cache, and app memory.

That's not what you are looking to benchmark.

Quoted 9 lines · Mike Fedyk

That was because they wanted the non-streaming files to be left in the cache.

Quoted 4 lines

I will try to produce some benchmarktings tomorrow with different
'mem=%dMB'. I'm afraid to confirm that it will make difference.
But in advance: mantainance of page tables for 1GB and for 128MB of
RAM are going to make a difference.

Quoted 7 lines

I'm sorry to say, but you *will* get lower performance if you lower the mem= value below your working set. This will also lower the total amount of memory available for your applications, and force your apps, to swap and balance cache, and app memory.

That's not what you are looking to benchmark.

Okay. I'm completely puzzled.
I will qute here only one test - and I really do not understand this
stuff.

Three boots with the same parameters and only mem=nMB, n =
{512,256,128} (I have 512MB RAM)

hdparm tests:
[root@hera ifilipau]# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 64 MB in 1.56 seconds = 41.03 MB/sec
[root@hera ifilipau]# hdparm -T /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.44 seconds =290.91 MB/sec
[root@hera ifilipau]#

Before tests I was doing 'swapoff -a; sync'
RedHat's 2.4.20-20.9 kernel.

What has really puzzled me.
Operation: "cat *.bz2 >big_file", where *.bz2 is just two bzipped
kernels. Total size: 29MB+32MB (2.4.22 + 2.6.0-test1)

To be bsolutely fair in this unfair benchmark I have run test only
once. Times in seconds as shown by bash's time.

cat sync

  512MB:  1.565    0.007
  256MB:  1.649    0.008
  128MB:  2.184    0.007

Kill me - shoot me, but how it can be?
Resulting file fits RAM.
Not hard to guess that source files, which no one cares about
already - are still hanging in the RAM...

That's not right: as long as resulting file fits memory - and it
fits memory in all (512MB, 256MB, 128MB) cases - this operation should take the _same_ time. (Actually before 128MB test, vmstat was saying that I have +70MB of free non-touched memory)

So resume is quite simple: kernel loses *terribly* much time
resorting read()s against write()s. Way _too_ _much_ time.