Re: la la la la ... swappiness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 03, 2006, at 20:54:41, Aucoin wrote:
As a side note, even now, *hours* after the tar has completed and even though I have swappiness set to 0, cache pressure set to 9999, all dirty timeouts set to 1 and all dirty ratios set to 1, I still have a 360+K inactive page count and my "free" memory is less than 10% of normal.

The point you're missing is that an "inactive" page is a free page that happens to have known clean data on it corresponding to something on disk. If you need to use the inactive page for something all you have to do is either zero it or fill it with data from elsewhere. There is _no_ practical reason for the kernel to turn an "inactive" page into a "free" page. On my Linux systems after heavy local-disk and network intensive read-only load I have no more than 2% "free" memory, most of the rest is "inactive" (in one case some 2GB of it). There's nothing _wrong_ with that much "inactive" memory, it just means that you were using it for data at one point, then didn't need it anymore and haven't reused it since.

I'm not pretending to understand what's happening here but shouldn't some kind of expiration have kicked in by now and freed up all those inactive pages?

Nope; the pages will continue to contain valid data until you overwrite them with new data somehow. Now, if they were "dirty" pages, containing unwritten data, then you would be correct.

The *instant* I manually push a "3" into drop_caches I have 100% of my normal free memory and the inactive page count drops below 2K. Maybe I completely misunderstood the purpose of all those dials but I really did get the feeling that twisting them all tight would make the housekeeping algorithms more aggressive.

In this case you're telling the kernel to go beyond its normal housekeeping and delete perfectly good data from memory. The only reason to do that is usually to make benchmarks mildly more repeatable and doing it on a regular basis tends to kill performance.

Cheers,
Kyle Moffett

[copy of long previous email snipped]

PS: No need to put a copy of the entire message you are replying to at the end of your post, it just chews up space. If anything please quote inline immediately before the appropriate portion of your reply so we can get the gist, much as I have done above.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux