Re: SuperPages utilization survey
On 07/06/2012 01:26, Florian Smeets wrote: On 05.06.12 16:29, Mark Felder wrote: On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets f...@freebsd.org wrote: As far as i understand it does at least enable usage of pages up to 4MB, perhaps someone should teach mysql about the FreeBSD's limits? If you look at the output i sent, it certainly changes from using no superpage mappings at all to using them to some degree, if you script can be trusted Wow, this is a nice find. If someone were to add a patch for FreeBSD's superpages we might be able to get a nice little performance boost with little effort. Even the increase to 4MB for now is a welcome improvement. I'll make sure to put this in my toolbox I played with this some more. MySQL does not seem to use superpages. After a mysqld restart Ivan's script and procstat showed superpage mappings for mysqld, but it seems once MySQL touches the memory it's not in superpages anymore. I looked at the MySQL code a bit and one would need to add FreeBSD support in a couple of places. Perhaps I'll find some time to try this, but i cannot make any promises. If I understand how superpages are promoted correctly, you may get a nice effect simply by changing malloc()s of 2MB+ sizes to calloc()s. signature.asc Description: OpenPGP digital signature
Re: SuperPages utilization survey
On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote: IV On 1 June 2012 14:35, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://people.freebsd.org/~ivoras/stuff/spsurvey.py ... IV If anyone posts more data, I'll analyse it. I'm more worried about the IV granularity of procstat, where it marks the entire region if a single IV superpage exists in it - it means any such analysis is only IV approximate. Here is a patch (for kernel and procstat) that allows to see amount of pages mapped to superpages. http://people.freebsd.org/~trociny/procstat-superpages.cnt.1.patch Not sure it is useful enough to be committed. -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote: On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote: IV On 1 June 2012 14:35, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://people.freebsd.org/~ivoras/stuff/spsurvey.py ... IV If anyone posts more data, I'll analyse it. I'm more worried about the IV granularity of procstat, where it marks the entire region if a single IV superpage exists in it - it means any such analysis is only IV approximate. Here is a patch (for kernel and procstat) that allows to see amount of pages mapped to superpages. http://people.freebsd.org/~trociny/procstat-superpages.cnt.1.patch Not sure it is useful enough to be committed. Superpage aggregates mappings for several normal-sized pages. As a consequence, when you iterate over small pages in sysctl_kern_proc_vmmap(), you account each superpage as many time as much constituent small pages it contains. pgpd9ymZ8zRqH.pgp Description: PGP signature
Re: SuperPages utilization survey
On Sat, 9 Jun 2012 11:38:22 +0300 Konstantin Belousov wrote: KB On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote: On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote: IV On 1 June 2012 14:35, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://people.freebsd.org/~ivoras/stuff/spsurvey.py ... IV If anyone posts more data, I'll analyse it. I'm more worried about the IV granularity of procstat, where it marks the entire region if a single IV superpage exists in it - it means any such analysis is only IV approximate. Here is a patch (for kernel and procstat) that allows to see amount of pages mapped to superpages. http://people.freebsd.org/~trociny/procstat-superpages.cnt.1.patch Not sure it is useful enough to be committed. KB Superpage aggregates mappings for several normal-sized pages. KB As a consequence, when you iterate over small pages in KB sysctl_kern_proc_vmmap(), you account each superpage as many time as KB much constituent small pages it contains. This is exactly what my intention was to count: how much memory are handled by superpages (using normal-sized page as a measurement unit), not amount of superpages. And I think this is what Ivan wanted to know. Do you think it is better to return number of superpages? -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On Sat, Jun 09, 2012 at 12:03:43PM +0300, Mikolaj Golub wrote: On Sat, 9 Jun 2012 11:38:22 +0300 Konstantin Belousov wrote: KB On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote: On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote: IV On 1 June 2012 14:35, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://people.freebsd.org/~ivoras/stuff/spsurvey.py ... IV If anyone posts more data, I'll analyse it. I'm more worried about the IV granularity of procstat, where it marks the entire region if a single IV superpage exists in it - it means any such analysis is only IV approximate. Here is a patch (for kernel and procstat) that allows to see amount of pages mapped to superpages. http://people.freebsd.org/~trociny/procstat-superpages.cnt.1.patch Not sure it is useful enough to be committed. KB Superpage aggregates mappings for several normal-sized pages. KB As a consequence, when you iterate over small pages in KB sysctl_kern_proc_vmmap(), you account each superpage as many time as KB much constituent small pages it contains. This is exactly what my intention was to count: how much memory are handled by superpages (using normal-sized page as a measurement unit), not amount of superpages. And I think this is what Ivan wanted to know. Do you think it is better to return number of superpages? Well, if I see a report informing me that some 2M region contains 512 super pages, how should I interpret it ? For me, it is only one superpage (mapping) that can be created in one 2M region. pgpjIsQYdxpkt.pgp Description: PGP signature
Re: SuperPages utilization survey
On Sat, 9 Jun 2012 12:07:40 +0300 Konstantin Belousov wrote: KB Well, if I see a report informing me that some 2M region contains 512 super KB pages, how should I interpret it ? For me, it is only one superpage (mapping) KB that can be created in one 2M region. Well, if I see a report like below: PID STARTEND PRTRES PRES SUP REF SHD FL TP PATH 485680x800c00x820c0 rw- 1310720 51712 2 0 --S df it tells me that for the region 0x800c0-0x820c0 (512Mb) we have 131072 * 4k = 512Mb resident and 51712 * 4k = 202Mb (a litle less than a half of the region) promoted (mapped) to superpages. If I had number of superpages here I would need additional knowledge (a superpage size) to calculate how effectively superpages are used. But actually, no much difference for me. To get a number of superpages is it enough just to divide the result obtained counting normal-sized pages by (2M/4k) factor? -- Mikolaj Golub ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 9 Jun 2012, at 10:46, Mikolaj Golub wrote: On Sat, 9 Jun 2012 12:07:40 +0300 Konstantin Belousov wrote: KB Well, if I see a report informing me that some 2M region contains 512 super KB pages, how should I interpret it ? For me, it is only one superpage (mapping) KB that can be created in one 2M region. Well, if I see a report like below: PID STARTEND PRTRES PRES SUP REF SHD FL TP PATH 485680x800c00x820c0 rw- 1310720 51712 2 0 --S df it tells me that for the region 0x800c0-0x820c0 (512Mb) we have 131072 * 4k = 512Mb resident and 51712 * 4k = 202Mb (a litle less than a half of the region) promoted (mapped) to superpages. If I had number of superpages here I would need additional knowledge (a superpage size) to calculate how effectively superpages are used. But actually, no much difference for me. To get a number of superpages is it enough just to divide the result obtained counting normal-sized pages by (2M/4k) factor? Remember also that superpage sizes are not necessarily 2M on all architectures, and in principle, many different page sizes might be simultaneously supported (e.g., on MIPS). I wonder if there's some way to capture that notion in the output somewhere so that, if we start supporting more granular page size control (something Alan might comment on), tool output doesn't need to be changed. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On Sat, Jun 09, 2012 at 12:46:53PM +0300, Mikolaj Golub wrote: On Sat, 9 Jun 2012 12:07:40 +0300 Konstantin Belousov wrote: KB Well, if I see a report informing me that some 2M region contains 512 super KB pages, how should I interpret it ? For me, it is only one superpage (mapping) KB that can be created in one 2M region. Well, if I see a report like below: PID STARTEND PRTRES PRES SUP REF SHD FL TP PATH 485680x800c00x820c0 rw- 1310720 51712 2 0 --S df it tells me that for the region 0x800c0-0x820c0 (512Mb) we have 131072 * 4k = 512Mb resident and 51712 * 4k = 202Mb (a litle less than a half of the region) promoted (mapped) to superpages. If I had number of superpages here I would need additional knowledge (a superpage size) to calculate how effectively superpages are used. But actually, no much difference for me. To get a number of superpages is it enough just to divide the result obtained counting normal-sized pages by (2M/4k) factor? First, there is nothing which would prevent demotion from happens while you iterate over the map, so you could get funyy numbers, like 42 superpages for 2M region with your method. Second, the superpage size if machine-depended, and even single machine could support differently sized superpage. For amd64, hardware can support 2M and 1G pages, and for i386 you can get 4M or 2M depending on PAE config. And last, I in fact do not see much use for any 'superpage count'. Would I would like to see is the TLB miss count for a region. Then I could estimate whether superpage enabling provided some advantage. Just as a note, if there were no accesses to a region after promotion, then promotion is the waste. Anyway, please do not consider this as discouraging you from doing a useful work. pgpv9Di6amoeA.pgp Description: PGP signature
Re: SuperPages utilization survey
On 9 Jun 2012, at 11:05, Konstantin Belousov wrote: First, there is nothing which would prevent demotion from happens while you iterate over the map, so you could get funyy numbers, like 42 superpages for 2M region with your method. Second, the superpage size if machine-depended, and even single machine could support differently sized superpage. For amd64, hardware can support 2M and 1G pages, and for i386 you can get 4M or 2M depending on PAE config. And last, I in fact do not see much use for any 'superpage count'. Would I would like to see is the TLB miss count for a region. Then I could estimate whether superpage enabling provided some advantage. Just as a note, if there were no accesses to a region after promotion, then promotion is the waste. Anyway, please do not consider this as discouraging you from doing a useful work. Despite the rendering and underlying semantic issues, I admit that I would like to know when superpages are being used by processes -- perhaps enough information to construct a histogram of page sizes for each mapping. Robert___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 05.06.12 16:29, Mark Felder wrote: On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets f...@freebsd.org wrote: As far as i understand it does at least enable usage of pages up to 4MB, perhaps someone should teach mysql about the FreeBSD's limits? If you look at the output i sent, it certainly changes from using no superpage mappings at all to using them to some degree, if you script can be trusted Wow, this is a nice find. If someone were to add a patch for FreeBSD's superpages we might be able to get a nice little performance boost with little effort. Even the increase to 4MB for now is a welcome improvement. I'll make sure to put this in my toolbox I played with this some more. MySQL does not seem to use superpages. After a mysqld restart Ivan's script and procstat showed superpage mappings for mysqld, but it seems once MySQL touches the memory it's not in superpages anymore. I looked at the MySQL code a bit and one would need to add FreeBSD support in a couple of places. Perhaps I'll find some time to try this, but i cannot make any promises. Florian signature.asc Description: OpenPGP digital signature
Re: SuperPages utilization survey
On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets f...@freebsd.org wrote: As far as i understand it does at least enable usage of pages up to 4MB, perhaps someone should teach mysql about the FreeBSD's limits? If you look at the output i sent, it certainly changes from using no superpage mappings at all to using them to some degree, if you script can be trusted Wow, this is a nice find. If someone were to add a patch for FreeBSD's superpages we might be able to get a nice little performance boost with little effort. Even the increase to 4MB for now is a welcome improvement. I'll make sure to put this in my toolbox ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
Hello, Ivan. You wrote 1 июня 2012 г., 16:23:42: IV http://people.freebsd.org/~ivoras/stuff/spsurvey_desktop.txt IV http://people.freebsd.org/~ivoras/stuff/spsurvey_mixserver.txt IV http://people.freebsd.org/~ivoras/stuff/spsurvey_webserver.txt Home storage server / torrent box: http://lev.serebryakov.spb.ru/_sklad/sps/spsurvey-home-storage-torrents.txt Web/Database/Mail all-in-one for me and my friends server: http://lev.serebryakov.spb.ru/_sklad/sps/spsurvey-mixed-web-database-mail.txt I'm surprised by number of Eligible mappings not promoted cases :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 02.06.12 10:14, Lev Serebryakov wrote: Hello, Ivan. You wrote 1 июня 2012 г., 16:23:42: IV http://people.freebsd.org/~ivoras/stuff/spsurvey_desktop.txt IV http://people.freebsd.org/~ivoras/stuff/spsurvey_mixserver.txt IV http://people.freebsd.org/~ivoras/stuff/spsurvey_webserver.txt Home storage server / torrent box: http://lev.serebryakov.spb.ru/_sklad/sps/spsurvey-home-storage-torrents.txt Web/Database/Mail all-in-one for me and my friends server: http://lev.serebryakov.spb.ru/_sklad/sps/spsurvey-mixed-web-database-mail.txt I'm surprised by number of Eligible mappings not promoted cases :( You have to explicitly enable it in mysql: add large-pages to the [mysqld] section of my.cnf Total accounted memory mappings: 7775 MB (1990412 pages) Memory in superpages: 5414 MB (3 mappings) pid: 27208 (mysqld) start: 80240 stop: 81680 (324 MB) tp: sw path: pid: 27208 (mysqld) start: 816c0 stop: 945628000 (4842 MB) tp: sw path: pid: 27208 (mysqld) start: 94580 stop: 95500 (248 MB) tp: sw path: Florian signature.asc Description: OpenPGP digital signature
Re: SuperPages utilization survey
You have to explicitly enable it in mysql: add large-pages to the [mysqld] section of my.cnf what actually this option do in mysql? Total accounted memory mappings: 7775 MB (1990412 pages) Memory in superpages: 5414 MB (3 mappings) pid: 27208 (mysqld) start: 80240 stop: 81680 (324 MB) tp: sw path: pid: 27208 (mysqld) start: 816c0 stop: 945628000 (4842 MB) tp: sw path: pid: 27208 (mysqld) start: 94580 stop: 95500 (248 MB) tp: sw path: Florian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 02.06.12 10:54, Wojciech Puchar wrote: You have to explicitly enable it in mysql: add large-pages to the [mysqld] section of my.cnf what actually this option do in mysql? In my words i would say It enables mysql to use super-pages/large-pages. The complete documentation is here https://dev.mysql.com/doc/refman/5.5/en/large-page-support.html Florian signature.asc Description: OpenPGP digital signature
Re: SuperPages utilization survey
In my words i would say It enables mysql to use super-pages/large-pages. i asked the question wrong. the right should be how does it do. Because i am not aware about any user level interface in FreeBSD to explicitly request superpage mapping. The complete documentation is here https://dev.mysql.com/doc/refman/5.5/en/large-page-support.html Florian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 2 June 2012 12:29, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote:
In my words i would say It enables mysql to use super-pages/large-pages.
i asked the question wrong. the right should be how does it do. Because i
am not aware about any user level interface in FreeBSD to explicitly request
superpage mapping.
You are right, there isn't any.
The code in mysqld.cc only works if HAVE_SOLARIS_LARGE_PAGES is defined:
3229 #endif /* HAVE_LARGE_PAGES */
3230 #ifdef HAVE_SOLARIS_LARGE_PAGES
3231 #define LARGE_PAGESIZE (4*1024*1024) /* 4MB */
3232 #define SUPER_LARGE_PAGESIZE (256*1024*1024) /* 256MB */
3233 if (opt_large_pages)
3234 {
...
3278 }
3279 #endif /* HAVE_SOLARIS_LARGE_PAGES */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
i asked the question wrong. the right should be how does it do. Because i
am not aware about any user level interface in FreeBSD to explicitly request
superpage mapping.
You are right, there isn't any.
true. anyway there should be such interface to freebsd kernel.
The code in mysqld.cc only works if HAVE_SOLARIS_LARGE_PAGES is defined:
3229 #endif /* HAVE_LARGE_PAGES */
3230 #ifdef HAVE_SOLARIS_LARGE_PAGES
3231 #define LARGE_PAGESIZE (4*1024*1024) /* 4MB */
3232 #define SUPER_LARGE_PAGESIZE (256*1024*1024) /* 256MB */
3233 if (opt_large_pages)
3234 {
...
3278 }
3279 #endif /* HAVE_SOLARIS_LARGE_PAGES */
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 02.06.12 12:48, Ivan Voras wrote:
On 2 June 2012 12:29, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote:
In my words i would say It enables mysql to use super-pages/large-pages.
i asked the question wrong. the right should be how does it do. Because i
am not aware about any user level interface in FreeBSD to explicitly request
superpage mapping.
You are right, there isn't any.
The code in mysqld.cc only works if HAVE_SOLARIS_LARGE_PAGES is defined:
3229 #endif /* HAVE_LARGE_PAGES */
3230 #ifdef HAVE_SOLARIS_LARGE_PAGES
3231 #define LARGE_PAGESIZE (4*1024*1024) /* 4MB */
3232 #define SUPER_LARGE_PAGESIZE (256*1024*1024) /* 256MB */
3233 if (opt_large_pages)
3234 {
...
3278 }
3279 #endif /* HAVE_SOLARIS_LARGE_PAGES */
As far as i understand it does at least enable usage of pages up to 4MB,
perhaps someone should teach mysql about the FreeBSD's limits?
If you look at the output i sent, it certainly changes from using no
superpage mappings at all to using them to some degree, if you script
can be trusted :)
Florian
signature.asc
Description: OpenPGP digital signature
SuperPages utilization survey
hello, I was wondering how much usage superpages get in real-world systems, and made a small script to parse the output of procstat -va: http://people.freebsd.org/~ivoras/stuff/spsurvey.py The results from three systems (with the script being run as root) are here: http://people.freebsd.org/~ivoras/stuff/spsurvey_desktop.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_mixserver.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_webserver.txt What I get from it is that they are really under-utilized, probably because it's a rare occasion that every single page in a 2 MB region is touched to enable its promotion. The only good case seems to be the third one, with the database accessing the whole memory range a lot, but the statistics which procstat reports is inaccurate: there could be only a single superpage in the whole region and procstat will make the region with the S flag. If there's anyone else wishing to run the script and post the results, it could be useful to see. signature.asc Description: OpenPGP digital signature
Re: SuperPages utilization survey
http://people.freebsd.org/~ivoras/stuff/spsurvey.py The results from three systems (with the script being run as root) are here: http://people.freebsd.org/~ivoras/stuff/spsurvey_desktop.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_mixserver.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_webserver.txt your webserver is actually database serwer with addons. mixserver - mix of what? My mixserver have certainly far different mix of your mixserver, as i don't use python heavily for example, while use squid, clamav (both fits well in superpages), and don't run large memory postgres process. What is desktop. A computer sitting on the desk? May run a lot of different programs. Your desktop as i can see use KDE bloatware and postgres. As for me, such namings are completely imprecise and such statistics say NOTHING. What REAL knowledge i acquired from your work is that postgres are very well fit for superpage mapping, if large DB buffer is used. Actually - Whenever there are long running processes in the system that allocate and use large memory chunks then superpage promotion will work. My idea - lets do a survey based on PROCESS NAME. this will give a really meaningful information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On 1 June 2012 14:35, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://people.freebsd.org/~ivoras/stuff/spsurvey.py The results from three systems (with the script being run as root) are here: http://people.freebsd.org/~ivoras/stuff/spsurvey_desktop.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_mixserver.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_webserver.txt your webserver is actually database serwer with addons. Database + apache + a lot of fairly large FastCGI php processes - which surprisingly don't use superpages. mixserver - mix of what? PostgreSQL, apache, php, dovecot, spamassasin, python web apps, and a lot of other things - I'm sure you can conclude from the list of processes. My mixserver have certainly far different mix of your mixserver, as i don't use python heavily for example, while use squid, clamav (both fits well in superpages), and don't run large memory postgres process. I'd like to learn more - can you post the results from your own server? What is desktop. A computer sitting on the desk? May run a lot of different programs. Your desktop as i can see use KDE bloatware and postgres. Yes, except for postgres which is used rarely, it's a fairly typical KDE desktop. As for me, such namings are completely imprecise and such statistics say NOTHING. Yes, a survey of three machines means nothing. I'm looking for more data. My idea - lets do a survey based on PROCESS NAME. this will give a really meaningful information. If anyone posts more data, I'll analyse it. I'm more worried about the granularity of procstat, where it marks the entire region if a single superpage exists in it - it means any such analysis is only approximate. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On Fri, 2012-06-01 at 14:23:42 +0200, Ivan Voras wrote: hello, I was wondering how much usage superpages get in real-world systems, and made a small script to parse the output of procstat -va: http://people.freebsd.org/~ivoras/stuff/spsurvey.py The results from three systems (with the script being run as root) are here: http://people.freebsd.org/~ivoras/stuff/spsurvey_desktop.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_mixserver.txt http://people.freebsd.org/~ivoras/stuff/spsurvey_webserver.txt What I get from it is that they are really under-utilized, probably because it's a rare occasion that every single page in a 2 MB region is touched to enable its promotion. The only good case seems to be the third one, with the database accessing the whole memory range a lot, but the statistics which procstat reports is inaccurate: there could be only a single superpage in the whole region and procstat will make the region with the S flag. If there's anyone else wishing to run the script and post the results, it could be useful to see. Here's output of a machine doing basically nothing all day: % fetch -o- http://people.freebsd.org/\~ivoras/stuff/spsurvey.py | sudo python - - 100% of 2035 B 664 kBps last pid: 20460; load averages: 0.04, 0.01, 0.00 up 2+01:35:3721:01:08 49 processes: 1 running, 48 sleeping Mem: 104M Active, 2079M Inact, 1593M Wired, 34M Cache, 418M Buf, 133M Free Swap: 4096M Total, 1376K Used, 4095M Free Total accounted memory mappings: 1669 MB (427314 pages) Memory in superpages: 12 MB (2 mappings) + pid: 864 (named) start: 80280 stop: 80300 (8 MB) tp: df path: + pid: 1002 (slapd) start: 80540 stop: 80580 (4 MB) tp: df path: Eligible mappings not promoted: 66 ... Also, what about kernel mappings? With ZFS and stuff there should be more superpages in kernel memory, no? Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
[/usr/home/feld]# python spsurvey.py last pid: 54743; load averages: 0.28, 0.26, 0.24 up 18+07:41:02 16:22:45 145 processes: 1 running, 144 sleeping Mem: 828M Active, 845M Inact, 8517M Wired, 174M Cache, 725M Buf, 265M Free Swap: 4096M Total, 88M Used, 4008M Free, 2% Inuse Total accounted memory mappings: 23968 MB (6136043 pages) Memory in superpages: 12941 MB (14 mappings) + pid: 26349 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26351 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26352 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26353 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26374 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26382 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26387 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26388 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26398 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 44306 (odasrv) start: 80180 stop: 80600 (72 MB) tp: df path: + pid: 44318 (odasrv) start: 80180 stop: 805c0 (68 MB) tp: df path: + pid: 53549 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 53932 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 54515 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: Eligible mappings not promoted: 413 Yup, seems like Postgres does a good job of using superpages ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
