On 4/28/05, Tzahi Fadida <[EMAIL PROTECTED]> wrote:
My next move was to try a big allocation like cacheman in windows
to free memory right now.
Maybe create a huge file?

Won't work - it will just mean you use up lots of space ON DISK,
you have to somehow convince the kernel that it wants to use
these RAM pages for something else and let go of the cached copies
of that other thing.

I don't know if it will work though, since the kernel has
to decide to somehow get rid of that particular caching.

Right-o.

Its not like i can target this.
Sync was the first thing i tried, and it had no effect.

As explained before.

Maybe there is proc setting or something like that
limits or disables this caching?

That's something for google or digging the kernel sources.
Let us know if you find anything.

Maybe i can rename/move/etc... the files of the database and
somehow the kernel will get the hint this cache is not
valid anymore.

Rename/move won't change it because the same disk data blocks
are still used for this.
A copy/delete might help but then again - the kernel might cache
the blocks it writes to the new copy.
Actually - it might help. There are two general options I can think of:
1. The kernel caches the blocks it wrote to the new copy - so it
means it let go of the cache of the old copy - use the OLD copy.
2. The kernel did NOT cache the new copy (but instead kept a cache
of the old file) - use the NEW copy.

And then again it might very well be that the kernel caching algorithm
is smarter than that (e.g. looking at how "sequencial" is this particular
file access and conclude that it's not worth to cache pages) and even
a copy won't help.

Have you tried to just write a program which allocates (and touches)
a lot of ram?

Something a-la:

main()
{
  char *cp = malloc(1024*1024*1024); /* 1GB */
  for (int i = 0; i < 1024 * 1024 * 1025; i += 1024)
     cp[i] = 1;
}

(it's not the most efficient program, it can probably be made a little more
efficient if you used steps by page sizes instead of "1024", though
efficiency is not the issue here).

The "touching" might be important because the kernel might not actually
allocate physical pages (and hopefully flush old cached copies of other stuff)
until they are actually used (I'm not up to date with the current kernel memory
management algorithms).

Regards,
        tzahi.

Cheers,

--Amos

Reply via email to