headers
Hareesh Nagarajan | 1 Dec 2005 03:35
Picon

Re: Better pagecache statistics ?

Hi,

Badari Pulavarty wrote:
> - How much is just file system cache (regular file data) ?

This is just a thought of mine:
/proc/slabinfo?

> - How much is shared memory pages ?
> - How much is mmaped() stuff ?

cat /proc/vmstat | grep nr_mapped
nr_mapped 77105

But yes, this doesn't give you a detailed account.

> - How much is for text, data, bss, heap, malloc ?

Again, this is just a thought of mine: Couldn't you get this information 
from /proc/≤pid>/maps or from the nicer and easier to parse procps 
application: pmap <pid>?

Thanks,

Hareesh
Permalink | Reply | 0 comments |
headers
Paul Jackson | 1 Dec 2005 15:44
Picon
Favicon

Re: [PATCH]: Free pages from local pcp lists under tight memory conditions

Rohit wrote:
> Can you please comment on the performance delta on the MPI workload
> because of this change in batch values. 

I can't -- all I know is what I read in Jack Steiner's posts
of April 5, 2005, referenced earlier in this thread.

--

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj <at> sgi.com> 1.925.600.0401
Permalink | Reply | 0 comments |
headers
Marcelo Tosatti | 1 Dec 2005 16:20
Picon

Re: Better pagecache statistics ?


Hi Badari,

On Wed, Nov 30, 2005 at 10:57:09AM -0800, Badari Pulavarty wrote:
> Hi,
> 
> Is there a effort/patches underway to provide better pagecache
> statistics ? 
> 
> Basically, I am interested in finding detailed break out of
> cached pages. ("Cached" in /proc/meminfo) 
> 
> Out of this "cached pages"
> 
> - How much is just file system cache (regular file data) ?
> - How much is shared memory pages ?

You could do that from userspace probably, by doing some math 
on all processes statistics versus global stats, but does not 
seem very practical.

> - How much is mmaped() stuff ?

That would be "nr_mapped".

> - How much is for text, data, bss, heap, malloc ?

Hum, the core pagecache code does not deal with such details, 
so adding (and maintaining) accounting there does not seem very 
practical either.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Badari Pulavarty | 1 Dec 2005 16:59
Picon
Favicon

Re: Better pagecache statistics ?

On Thu, 2005-12-01 at 13:20 -0200, Marcelo Tosatti wrote:
> Hi Badari,
> 
> On Wed, Nov 30, 2005 at 10:57:09AM -0800, Badari Pulavarty wrote:
> > Hi,
> > 
> > Is there a effort/patches underway to provide better pagecache
> > statistics ? 
> > 
> > Basically, I am interested in finding detailed break out of
> > cached pages. ("Cached" in /proc/meminfo) 
> > 
> > Out of this "cached pages"
> > 
> > - How much is just file system cache (regular file data) ?
> > - How much is shared memory pages ?
> 
> You could do that from userspace probably, by doing some math 
> on all processes statistics versus global stats, but does not 
> seem very practical.
> 
> > - How much is mmaped() stuff ?
> 
> That would be "nr_mapped".
> 
> > - How much is for text, data, bss, heap, malloc ?
> 
> Hum, the core pagecache code does not deal with such details, 
> so adding (and maintaining) accounting there does not seem very 
> practical either.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo Tosatti | 1 Dec 2005 17:00
Picon

Re: Better pagecache statistics ?

On Thu, Dec 01, 2005 at 01:20:29PM -0200, Marcelo Tosatti wrote:
> 
> Hi Badari,
> 
> On Wed, Nov 30, 2005 at 10:57:09AM -0800, Badari Pulavarty wrote:
> > Hi,
> > 
> > Is there a effort/patches underway to provide better pagecache
> > statistics ? 
> > 
> > Basically, I am interested in finding detailed break out of
> > cached pages. ("Cached" in /proc/meminfo) 
> > 
> > Out of this "cached pages"
> > 
> > - How much is just file system cache (regular file data) ?
> > - How much is shared memory pages ?
> 
> You could do that from userspace probably, by doing some math 
> on all processes statistics versus global stats, but does not 
> seem very practical.

Actually, SysRQ-M reports "N pages shared".
Permalink | Reply | 0 comments |
headers
Arjan van de Ven | 1 Dec 2005 17:10
Favicon

Re: Better pagecache statistics ?


> Out of "Cached" value - to get details like
> 
> 	<mmap> - xxx KB
> 	<shared mem> - xxx KB
> 	<text, data, bss, malloc, heap, stacks> - xxx KB
> 	<filecache pages total> -- xxx KB
> 		(filename1 or <dev>, <ino>) -- #of pages
> 		(filename2 or <dev>, <ino>) -- #of pages
> 		
> This would be really powerful on understanding system better.

to some extend it might be useful.
I have a few concerns though
1) If we make these stats into an ABI then it becomes harder to change
the architecture of the VM radically since such concepts may not even
exist in the new architecture. As long as this is some sort of advisory,
humans-only file I think this isn't too much of a big deal though.

2) not all the concepts you mention really exist as far as the kernel is
concerned. I mean.. a mmap file is file cache is .. etc.
malloc/heap/stacks are also not differentiated too much and are mostly
userspace policy (especially thread stacks). 

A split in
* non-file backed
  - mapped once
  - mapped more than once
* file backed
  - mapped at least once
(Continue reading)

Permalink | Reply | 0 comments |
headers
Badari Pulavarty | 1 Dec 2005 17:23
Picon
Favicon

Re: Better pagecache statistics ?

On Thu, 2005-12-01 at 17:10 +0100, Arjan van de Ven wrote:
> > Out of "Cached" value - to get details like
> > 
> > 	<mmap> - xxx KB
> > 	<shared mem> - xxx KB
> > 	<text, data, bss, malloc, heap, stacks> - xxx KB
> > 	<filecache pages total> -- xxx KB
> > 		(filename1 or <dev>, <ino>) -- #of pages
> > 		(filename2 or <dev>, <ino>) -- #of pages
> > 		
> > This would be really powerful on understanding system better.
> 
> to some extend it might be useful.
> I have a few concerns though
> 1) If we make these stats into an ABI then it becomes harder to change
> the architecture of the VM radically since such concepts may not even
> exist in the new architecture. As long as this is some sort of advisory,
> humans-only file I think this isn't too much of a big deal though.

ABI or API ? yuck. I am thinking more like a /proc/cachedetail like
thing (mostly for debug).

> 
> 2) not all the concepts you mention really exist as far as the kernel is
> concerned. I mean.. a mmap file is file cache is .. etc.
> malloc/heap/stacks are also not differentiated too much and are mostly
> userspace policy (especially thread stacks). 
> 
> A split in
> * non-file backed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo Tosatti | 1 Dec 2005 18:08
Picon

Re: Better pagecache statistics ?

On Thu, Dec 01, 2005 at 05:10:11PM +0100, Arjan van de Ven wrote:
> > Out of "Cached" value - to get details like
> > 
> > 	<mmap> - xxx KB
> > 	<shared mem> - xxx KB
> > 	<text, data, bss, malloc, heap, stacks> - xxx KB
> > 	<filecache pages total> -- xxx KB
> > 		(filename1 or <dev>, <ino>) -- #of pages
> > 		(filename2 or <dev>, <ino>) -- #of pages
> > 		
> > This would be really powerful on understanding system better.
> 
> to some extend it might be useful.
> I have a few concerns though
> 1) If we make these stats into an ABI then it becomes harder to change
> the architecture of the VM radically since such concepts may not even
> exist in the new architecture. As long as this is some sort of advisory,
> humans-only file I think this isn't too much of a big deal though. 
> 
> 2) not all the concepts you mention really exist as far as the kernel is
> concerned. I mean.. a mmap file is file cache is .. etc.
> malloc/heap/stacks are also not differentiated too much and are mostly
> userspace policy (especially thread stacks). 
> 
> A split in
> * non-file backed
>   - mapped once
>   - mapped more than once
> * file backed
>   - mapped at least once
(Continue reading)

Permalink | Reply | 0 comments |
headers
Badari Pulavarty | 1 Dec 2005 18:15
Picon
Favicon

Re: Better pagecache statistics ?

On Thu, 2005-12-01 at 15:08 -0200, Marcelo Tosatti wrote:
> On Thu, Dec 01, 2005 at 05:10:11PM +0100, Arjan van de Ven wrote:
> > > Out of "Cached" value - to get details like
> > > 
> > > 	<mmap> - xxx KB
> > > 	<shared mem> - xxx KB
> > > 	<text, data, bss, malloc, heap, stacks> - xxx KB
> > > 	<filecache pages total> -- xxx KB
> > > 		(filename1 or <dev>, <ino>) -- #of pages
> > > 		(filename2 or <dev>, <ino>) -- #of pages
> > > 		
> > > This would be really powerful on understanding system better.
> > 
> > to some extend it might be useful.
> > I have a few concerns though
> > 1) If we make these stats into an ABI then it becomes harder to change
> > the architecture of the VM radically since such concepts may not even
> > exist in the new architecture. As long as this is some sort of advisory,
> > humans-only file I think this isn't too much of a big deal though. 
> > 
> > 2) not all the concepts you mention really exist as far as the kernel is
> > concerned. I mean.. a mmap file is file cache is .. etc.
> > malloc/heap/stacks are also not differentiated too much and are mostly
> > userspace policy (especially thread stacks). 
> > 
> > A split in
> > * non-file backed
> >   - mapped once
> >   - mapped more than once
> > * file backed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arjan van de Ven | 1 Dec 2005 18:21
Favicon

Re: Better pagecache statistics ?

On Thu, 2005-12-01 at 09:15 -0800, Badari Pulavarty wrote:
> > Most of the issues you mention are null if you move the stats
> > maintenance burden to userspace. 
> > 
> > The performance impact is also minimized since the hooks 
> > (read: overhead) can be loaded on-demand as needed.
> > 
> 
> The overhead is - going through each mapping/inode in the system
> and dumping out "nrpages" - to get per-file statistics. This is
> going to be expensive, need locking and there is no single list 
> we can traverse to get it. I am not sure how to do this.

and worse... you're going to need memory to store the results, either in
kernel or in userspace, and you don't know how much until you're done.
That memory is going to need to be allocated, which in turn changes the
vm state..
Permalink | Reply | 0 comments |

Gmane