Ok, I'll double check to validate that there is true duplication.
If shared memory cannot be swapped, and shows up in the page cache list (wh=
ich would be odd, but ok, since shared mem is not page cache it is applicat=
ion memory), then only those pages (the actual shared_buffers) would not be=
swappable, not a 'clone' of those buffers in the os page cache.
I certainly don't care if the shared memory isn't pageable, I do care if a =
clone of that memory is also not pageable.
________________________________________
From: Pavan Deolasee [pavan.deolasee@gmail.com]
Sent: Thursday, December 11, 2008 12:35 AM
To: Scott Carey
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned (dup=
licated by OS, always)
On Thu, Dec 11, 2008 at 5:37 AM, Scott Carey <scott@richrelevance.com> wrot=
e:
>
>
> Run top, and note the largest value of the "SHR" column on all postgres
> processes. Now execute the os cache eviction. Check the remaining cached
> memory.
> Note that it is now larger than the baseline by essentially the exact size
> of the postgres shared memory.
>
Isn't the shared memory on Linux non-swappable, unlike Solaris where
you have an option to make is swappable ? As and when shared memory
pages are accessed, they are allocated and can not be swapped out. I
don't know if these pages are counted as part of the OS cache, but
assuming they are, I don't see any problem with the above observation.
May be you can try to write a C program which creates, attaches and
accesses every page of the shared memory and check if you see the same
behavior.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com