From roland.mainz at nrubsig.org Thu Jan 1 11:36:20 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu, 01 Jan 2009 20:36:20 +0100 Subject: [emancipation-discuss] "emancipation" mailman archive broken ? Message-ID: <495D1B34.F336FC8D@nrubsig.org> Hi! ---- Is it possible that the "emancipation" mailman archive (e.g. http://mail.opensolaris.org/pipermail/emancipation-discuss/) missies some emails or was there no discussion in November/December ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Thu Jan 1 13:22:01 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu, 01 Jan 2009 22:22:01 +0100 Subject: [emancipation-discuss] [osol-discuss] Memory requirements of Solaris/OpenSolaris... /was: Re: [tools-discuss] Project Proposal -- Port toMIPSarchitecture References: <663303.49565.qm@web111306.mail.gq1.yahoo.com> Message-ID: <495D33F9.200D9ED6@nrubsig.org> ken mays wrote: [snip] > > Mark Martin wrote: [snip] > > Assuming you only use UFS and cut-down some system > > tuneables Solaris can > > run on a 64MB machine (my Ultra5 only has 128MB now after > > one of the > > DIMMs failed and it still works fine with CDE). The > > problems start if > > you want to run some of the memory-hogs, e.g. ZFS, JAVA or > > a X11 server > > - then you either need a swap device or much more memory. > > You should take to the 32MB of RAM level. How about playback of MPEG-2 streams or MP3 audio using OpenSolaris in a 32 MB RAM embedded environment solution. Booting plain OpenSolaris with a 32MB machine may be possible (remember original versions of Solaris 2.x had no problems with that) ... but MPEG-2 video stream playback will itself consume lots of memory since you have to do buffering, including I frames, data for the P/B frames etc. ... and system stream playback (system stream == interleaved video+audio streams) will require even more memory. I don't know whether this is possible... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From roland.mainz at nrubsig.org Thu Jan 1 11:16:40 2009 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu, 01 Jan 2009 20:16:40 +0100 Subject: [emancipation-discuss] Memory requirements of Solaris/OpenSolaris... / was: Re: [tools-discuss] [osol-discuss] Project Proposal -- Port to MIPSarchitecture References: Message-ID: <495D1698.789140EB@nrubsig.org> Mark Martin wrote: > > [Resent for Reply-all] > > On Sat, Oct 18, 2008 at 6:03 PM, Martin Bochnig > wrote: > > +1 > > Except that it would be nice if somebody would make the > Polaris port functional, before starting a new port. > Also, why MIPS, not ARM? Isn't MIPS dead a bit? > > Thanks for the vote and the feedback. > > I believe the PowerPC is either lacking consensus on a platform or > lacking other resources (or both). I agree that the PowerPC has some > attractive features, but lack of a valid, available platform and > resources I think is contributing to its dormancy. I believe that > interest continues for that platform, but once Sun Labs discontinued > development support, the project seems to have gone into hibernation. > > Someone mentioned interest in an ARM a short while ago, but in my > research, I could not find a solid, available platform that provided > enough physical resources -- namely 256MB to 512MB RAM, Assuming you only use UFS and cut-down some system tuneables Solaris can run on a 64MB machine (my Ultra5 only has 128MB now after one of the DIMMs failed and it still works fine with CDE). The problems start if you want to run some of the memory-hogs, e.g. ZFS, JAVA or a X11 server - then you either need a swap device or much more memory. Beyond that I think we need a project which works on lowering the memory footprint of Solaris - for example as I already wrote in http://mail.opensolaris.org/pipermail/opensolaris-code/2007-March/004430.html -- snip -- > Another issue is the way how applications in Solaris allocate temporary > memory (this applies to the kernel but a "solution" is much more tricky > because the kernel's stack can't grow which limits it to 4k on i86 and > 8k on UltraSPARC (UltraSPARC may be in a better position since it could > map the stack with 64k pages (which runs into other problems since lots > of code doesn't expect a "custom" page size for kernel stacks... ;-(( > ))) - IMO in many places the usage of |malloc()| should be replaced with > |alloca()| or C99's variable length arrays assuming the size does not > exceed a given size (some sample code can be found in > http://mail.opensolaris.org/pipermail/perf-discuss/2007-February/001589.html). > This solution would have lots of advantages, for example: > - Multithreaded applications would not go through the heap each time, > e.g. avoid locking/syscall overhead in the worst case > - Better locality of data - the thread's stack is assumed to be closer > to the running CPU than a "random" page in the heap > - It is "easier" (the explanation of this is little bit beyond the scope > of this email, basically some UltraSPARC CPUs seems to have trouble > handling more than two different pagsizes at the same time except the > number of pages for a 3rd/4th size is very small) to map the stack with > largepages than the whole heap of an application > - Avoid taxing the heap with lots of small temporary allocations -- snip -- If we could fix the way how these allocations are done many issues with memory wasting and kernel allocator scalability (or better: Many temporary allocations will done in the per-thread memory "stack" and no longer go through the SLAB code) will simply go away. ---- Bye, Roland P.S.: Setting Reply-To: to on-discuss at opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From maybird1776 at yahoo.com Thu Jan 1 12:36:04 2009 From: maybird1776 at yahoo.com (ken mays) Date: Thu, 1 Jan 2009 12:36:04 -0800 (PST) Subject: [emancipation-discuss] [osol-discuss] Memory requirements of Solaris/OpenSolaris... / was: Re: [tools-discuss] Project Proposal -- Port to MIPSarchitecture In-Reply-To: <495D1698.789140EB@nrubsig.org> Message-ID: <663303.49565.qm@web111306.mail.gq1.yahoo.com> --- On Thu, 1/1/09, Roland Mainz wrote: > From: Roland Mainz > Subject: [osol-discuss] Memory requirements of Solaris/OpenSolaris... / was: Re: [tools-discuss] Project Proposal -- Port to MIPSarchitecture > To: "Mark Martin" > Cc: emancipation-discuss at opensolaris.org, "Open Solaris" , tools-discuss at opensolaris.org, "powerpc" , "on-discuss at opensolaris.org" > Date: Thursday, January 1, 2009, 2:16 PM > Mark Martin wrote: > > > > [Resent for Reply-all] > > > > On Sat, Oct 18, 2008 at 6:03 PM, Martin Bochnig > > > wrote: > > > > +1 > > > > Except that it would be nice if somebody would > make the > > Polaris port functional, before starting a new > port. > > Also, why MIPS, not ARM? Isn't MIPS dead a > bit? > > > > Thanks for the vote and the feedback. > > > > I believe the PowerPC is either lacking consensus on a > platform or > > lacking other resources (or both). I agree that the > PowerPC has some > > attractive features, but lack of a valid, available > platform and > > resources I think is contributing to its dormancy. I > believe that > > interest continues for that platform, but once Sun > Labs discontinued > > development support, the project seems to have gone > into hibernation. > > > > Someone mentioned interest in an ARM a short while > ago, but in my > > research, I could not find a solid, available platform > that provided > > enough physical resources -- namely 256MB to 512MB > RAM, > > Assuming you only use UFS and cut-down some system > tuneables Solaris can > run on a 64MB machine (my Ultra5 only has 128MB now after > one of the > DIMMs failed and it still works fine with CDE). The > problems start if > you want to run some of the memory-hogs, e.g. ZFS, JAVA or > a X11 server > - then you either need a swap device or much more memory. Hi Roland, You should take to the 32MB of RAM level. How about playback of MPEG-2 streams or MP3 audio using OpenSolaris in a 32 MB RAM embedded environment solution. Ken From dclarke at blastwave.org Thu Jan 1 14:16:52 2009 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 01 Jan 2009 17:16:52 -0500 (EST) Subject: [emancipation-discuss] [osol-discuss] Memory requirements of Solaris/OpenSolaris... /was: Re: [tools-discuss] Project Proposal -- Port toMIPSarchitecture Message-ID: <53202.10.0.66.17.1230848212.squirrel@interact.purplecow.org> > ken mays wrote: > [snip] >> > Mark Martin wrote: > [snip] >> > Assuming you only use UFS and cut-down some system >> > tuneables Solaris can >> > run on a 64MB machine (my Ultra5 only has 128MB now after >> > one of the >> > DIMMs failed and it still works fine with CDE). The >> > problems start if >> > you want to run some of the memory-hogs, e.g. ZFS, JAVA or >> > a X11 server >> > - then you either need a swap device or much more memory. >> >> You should take to the 32MB of RAM level. How about playback of MPEG-2 >> streams or MP3 audio using OpenSolaris in a 32 MB RAM embedded >> environment solution. > > Booting plain OpenSolaris with a 32MB machine may be possible (remember > original versions of Solaris 2.x had no problems with that) ... but > MPEG-2 video stream playback will itself consume lots of memory since > you have to do buffering, including I frames, data for the P/B frames > etc. ... and system stream playback (system stream == interleaved > video+audio streams) will require even more memory. I don't know whether > this is possible... > I did perform some low memory test experiments and I can tell you ( with plenty of data ) that a Solaris machine pushed to do any work with low memory will rapidly become a space heater. You may get a response from the console ... or not. Either way, 1GB of memory should be seen as the rock bottom minimal config these days. $ su - Password: Feb 25 12:53:45 aequitas su: 'su root' succeeded for dclarke on /dev/console Sun Microsystems Inc. SunOS 5.11 gazelle Dec. 12, 2007 SunOS Internal Development: dclarke 2007-12-12 [gazelle] bfu'ed from /export/gazelle/archives/i386/nightly on 2007-12-12 Sun Microsystems Inc. SunOS 5.11 snv_70b October 2007 # mdb -k Loading modules: [ unix genunix specfs cpu.generic uppc pcplusmp scsi_vhci ufs ip hook neti sctp arp usba uhci fctl nca lofs zfs random fcip logindmux ptm sppp ] > pageout_new_spread/X pageout_new_spread: pageout_new_spread: 27702 > handspreadpages/X handspreadpages: handspreadpages:5b3e > lotsfree/X lotsfree: lotsfree: 2d9 > deficit/X deficit: deficit: 0 > slowscan/X slowscan: slowscan: 64 > fastscan/X fastscan: fastscan: 5b3e > minfree/X minfree: minfree: b6 Please take note of lotsfree, fastscan and minfree there. Here comes the situation after attempting to compile the ON kernel after 40 days of non-stop load with 192MB of memory : [ I hope this doesn't line wrap at 72 chars ] > ::kmastat cache buf buf buf memory alloc alloc name size in use total in use succeed fail ------------------------- ------ ------ ------ ---------- --------- ----- kmem_magazine_1 8 19 507 12288B 123304 0 kmem_magazine_3 16 80 1143 36864B 904298 0 kmem_magazine_7 32 77 1134 73728B 2126812 0 kmem_magazine_15 64 61 341 45056B 7193629 0 kmem_magazine_31 128 0 0 0B 0 0 kmem_magazine_47 192 0 0 0B 0 0 kmem_magazine_63 256 0 0 0B 0 0 kmem_magazine_95 384 0 0 0B 0 0 kmem_magazine_143 576 0 0 0B 0 0 kmem_slab_cache 28 15151 15288 745472B 825744 0 kmem_bufctl_cache 12 4 127 4096B 4 0 kmem_bufctl_audit_cache100 558650 558657 69341184B 23614865 0 kmem_va_4096 4096 9439 9440 38666240B 50389 0 kmem_va_8192 8192 454 496 4063232B 43692 0 kmem_va_12288 12288 546 970 12713984B 55116 0 kmem_va_16384 16384 6 8 131072B 7 0 kmem_va_20480 20480 65 78 1703936B 511 0 kmem_va_24576 24576 0 0 0B 0 0 kmem_va_28672 28672 8 8 262144B 12 0 kmem_va_32768 32768 0 0 0B 0 0 kmem_alloc_8 8 9639 15130 364544B 24894004 0 kmem_alloc_16 16 10197 13952 446464B 8540073 0 kmem_alloc_24 24 7830 13260 532480B 32802752 0 kmem_alloc_32 32 10916 17340 835584B 11617539 0 kmem_alloc_40 40 8786 12118 679936B 13100776 0 kmem_alloc_48 48 7278 10752 688128B 2209134 0 kmem_alloc_56 56 2146 5320 389120B 1782146 0 kmem_alloc_64 64 936 3168 405504B 47759338 0 kmem_alloc_80 80 4305 5964 581632B 2309670 0 kmem_alloc_96 96 1311 2016 229376B 279376 0 kmem_alloc_112 112 177 448 57344B 733256 0 kmem_alloc_128 128 117 189 36864B 3054652 0 kmem_alloc_160 160 4744 5129 913408B 374585519 0 kmem_alloc_192 192 92 144 36864B 1091937 0 kmem_alloc_224 224 158 255 61440B 569504 0 kmem_alloc_256 256 46 120 40960B 25769797 0 kmem_alloc_320 320 132 170 69632B 306780 0 kmem_alloc_384 384 75 99 45056B 21236385 0 kmem_alloc_448 448 60 104 53248B 370965552 0 kmem_alloc_512 512 439 749 438272B 7453983 0 kmem_alloc_640 640 84 121 90112B 2100802 0 kmem_alloc_768 768 5 18 16384B 26164 0 kmem_alloc_896 896 6 16 16384B 28057 0 kmem_alloc_1152 1152 239 300 368640B 35393797 0 kmem_alloc_1344 1344 15 24 36864B 8536 0 kmem_alloc_1600 1600 9 21 36864B 243777 0 kmem_alloc_2048 2048 28 45 102400B 207148 0 kmem_alloc_2688 2688 174 182 532480B 728408 0 kmem_alloc_4096 4096 390 391 3203072B 1170300 0 kmem_alloc_8192 8192 504 505 6205440B 2421868 0 kmem_alloc_12288 12288 4 6 98304B 2468 0 kmem_alloc_16384 16384 18 20 409600B 1219 0 kmem_alloc_24576 24576 5 7 200704B 40 0 kmem_alloc_32768 32768 7 9 331776B 161 0 streams_mblk 32 3624 4288 274432B 3622918 0 streams_dblk_64 128 333 420 81920B 1876293 0 streams_dblk_128 192 6 160 40960B 1168777 0 streams_dblk_320 384 212 306 139264B 91582 0 streams_dblk_576 640 0 11 8192B 6767 0 streams_dblk_1088 1152 1 20 24576B 83908 0 streams_dblk_1536 1600 2 7 12288B 32547 0 streams_dblk_1984 2048 0 9 20480B 380 0 streams_dblk_2624 2688 0 7 20480B 497 0 streams_dblk_3968 4032 0 1 4096B 312 0 streams_dblk_8192 64 0 64 8192B 179473 0 streams_dblk_12160 12224 0 2 24576B 869 0 streams_dblk_16384 64 0 32 4096B 16 0 streams_dblk_20352 20416 0 0 0B 0 0 streams_dblk_24576 64 0 0 0B 0 0 streams_dblk_28544 28608 0 1 28672B 1 0 streams_dblk_32768 64 0 0 0B 0 0 streams_dblk_36736 36800 0 0 0B 0 0 streams_dblk_40960 64 0 0 0B 0 0 streams_dblk_44928 44992 0 0 0B 0 0 streams_dblk_49152 64 0 0 0B 0 0 streams_dblk_53120 53184 0 1 53248B 1 0 streams_dblk_57344 64 0 0 0B 0 0 streams_dblk_61312 61376 0 0 0B 0 0 streams_dblk_65536 64 0 32 4096B 48 0 streams_dblk_69504 69568 0 0 0B 0 0 streams_dblk_73728 64 0 0 0B 0 0 streams_dblk_esb 64 3072 3104 397312B 251848 0 streams_fthdr 168 0 0 0B 0 0 streams_ftblk 152 0 0 0B 0 0 multidata 136 0 0 0B 0 0 multidata_pdslab 3560 0 0 0B 0 0 multidata_pattbl 20 0 0 0B 0 0 log_cons_cache 32 5 85 4096B 48 0 taskq_ent_cache 28 499 765 36864B 6154586 0 taskq_cache 160 49 69 12288B 130 0 kmem_io_256M_128 128 0 16 4096B 5 0 kmem_io_256M_256 256 1 8 4096B 4 0 kmem_io_256M_512 512 1 4 4096B 2 0 kmem_io_256M_1024 1024 0 2 4096B 175 0 kmem_io_256M_2048 2048 4096 4098 16785408B 12342 0 kmem_io_256M_4096 4096 0 0 0B 0 0 kmem_io_16M_128 128 0 0 0B 0 0 kmem_io_16M_256 256 0 0 0B 0 0 kmem_io_16M_512 512 0 0 0B 0 0 kmem_io_16M_1024 1024 0 0 0B 0 0 kmem_io_16M_2048 2048 0 0 0B 0 0 kmem_io_16M_4096 4096 0 0 0B 0 0 id32_cache 32 0 64 4096B 64239 0 bp_map_4096 4096 0 0 0B 559490 0 bp_map_8192 8192 0 0 0B 43003 0 bp_map_12288 12288 0 0 0B 2 0 bp_map_16384 16384 0 0 0B 0 0 bp_map_20480 20480 0 0 0B 0 0 bp_map_24576 24576 0 0 0B 0 0 bp_map_28672 28672 0 0 0B 0 0 bp_map_32768 32768 0 0 0B 0 0 htable_t 40 1174 1919 77824B 7546278 0 hment_t 24 281 8281 200704B 482129677 0 hat_t 96 63 108 12288B 1274030 0 HatHash 256 63 90 24576B 1314516 0 segkp_4096 4096 54 64 262144B 599800 0 segkp_8192 8192 0 0 0B 0 0 segkp_12288 12288 341 375 4915200B 3738528 0 segkp_16384 16384 0 0 0B 0 0 segkp_20480 20480 0 0 0B 52084 0 umem_np_4096 4096 0 0 0B 630 0 umem_np_8192 8192 0 0 0B 619 0 umem_np_12288 12288 0 0 0B 610 0 umem_np_16384 16384 0 0 0B 9 0 umem_np_20480 20480 0 0 0B 0 0 umem_np_24576 24576 0 0 0B 2 0 umem_np_28672 28672 0 0 0B 0 0 umem_np_32768 32768 0 0 0B 9 0 mod_hash_entries 12 297 512 16384B 14649 0 ipp_mod 284 0 0 0B 0 0 ipp_action 328 0 0 0B 0 0 ipp_packet 40 0 0 0B 0 0 seg_cache 44 2382 3904 249856B 45240441 0 snode_cache 88 159 195 20480B 97009 0 dv_node_cache 72 41 138 12288B 5137 0 sdev_node_cache 116 1054 1080 147456B 4946 0 dev_info_node_cache 328 141 154 57344B 19907 0 thread_cache 512 196 240 131072B 832768 0 lwp_cache 1092 196 231 270336B 189281 0 turnstile_cache 36 341 584 32768B 4741677 0 tslabel_cache 48 2 64 4096B 2 0 cred_cache 164 52 66 12288B 11430 0 rctl_cache 24 912 1530 61440B 8529338 0 rctl_val_cache 44 1825 2496 159744B 18776368 0 task_cache 76 26 42 4096B 227 0 rootnex_dmahdl 1272 4118 4125 5632000B 370343736 0 timeout_request 80 2 42 4096B 3 0 cyclic_id_cache 32 4 85 4096B 4 0 dnlc_space_cache 16 0 128 4096B 22122 0 vfs_cache 108 32 37 4096B 77 0 vn_cache 160 5779 12264 2392064B 4293920 0 vsk_anchor_cache 24 11 170 4096B 15 0 file_cache 36 292 730 40960B 22494177 0 stream_head_cache 232 101 144 36864B 340616 0 queue_cache 356 194 220 90112B 350708 0 syncq_cache 100 8 34 4096B 130547 0 qband_cache 32 2 85 4096B 2 0 linkinfo_cache 24 3 102 4096B 3 0 serializer_cache 40 21 73 4096B 128 0 as_cache 116 62 120 16384B 1274029 0 marker_cache 80 0 42 4096B 673272 0 anon_cache 24 378995 379015 18264064B 188488217 0 anonmap_cache 32 1581 2975 143360B 17126080 0 segvn_cache 92 2382 3564 405504B 29258059 0 segvn_szc_cache1 2048 0 4 8192B 1741256 0 flk_edges 24 0 102 4096B 1 0 fdb_cache 64 0 0 0B 0 0 timer_cache 84 0 39 4096B 4 0 vmu_bound_cache 16 0 0 0B 0 0 vmu_object_cache 16 0 0 0B 0 0 physio_buf_cache 136 0 26 4096B 520 0 ufs_inode_cache 276 3970 8307 2617344B 1439770 0 directio_buf_cache 148 0 0 0B 0 0 lufs_save 12 0 128 4096B 361836 0 lufs_bufs 140 0 25 4096B 361836 0 lufs_mapentry_cache 64 44 204 16384B 8679222 0 kcf_sreq_cache 36 0 0 0B 0 0 kcf_areq_cache 172 0 0 0B 0 0 kcf_context_cache 60 0 0 0B 0 0 ip_minor_arena_1 1 24 64 64B 3943 0 ip_conn_cache 956 1 4 4096B 3 0 tcp_conn_cache 1856 15 20 40960B 226 0 udp_conn_cache 1276 7 12 16384B 3706 0 rawip_conn_cache 1228 0 3 4096B 3 0 rts_conn_cache 992 2 4 4096B 6 0 ire_cache 252 15 30 8192B 2195 0 rt_entry 100 2 34 4096B 3 0 radix_mask 16 1 128 4096B 1 0 radix_node 64 1 51 4096B 1 0 ipsec_actions 60 0 68 4096B 43629 0 ipsec_selectors 68 0 0 0B 0 0 ipsec_policy 48 0 0 0B 0 0 ipsec_info 216 0 18 4096B 43645 0 tcp_timercache 44 17 64 4096B 263 0 tcp_sack_info_cache 72 0 46 4096B 32 0 tcp_iphc_cache 120 14 30 4096B 225 0 squeue_cache 180 2 16 4096B 2 0 sctp_conn_cache 2144 1 9 20480B 1 0 sctp_faddr_cache 140 0 0 0B 0 0 sctp_set_cache 16 0 0 0B 0 0 sctp_ftsn_set_cache 8 0 0 0B 0 0 ire_gw_secattr_cache 20 0 0 0B 0 0 sctpsock 432 0 0 0B 0 0 sctp_assoc 44 0 0 0B 0 0 sdpsock 392 0 0 0B 0 0 socktpi_cache 308 12 24 8192B 3413 0 socktpi_unix_cache 308 15 24 8192B 117 0 mac_impl_cache 320 1 12 4096B 2 0 mac_vnic_tx_cache 28 0 0 0B 0 0 dls_cache 104 2 34 4096B 7 0 soft_ring_cache 136 0 0 0B 0 0 dls_vlan_cache 48 1 64 4096B 2 0 dls_link_cache 328 1 11 4096B 2 0 dld_ctl_1 1 0 0 0B 0 0 drv_secobj_cache 296 0 0 0B 0 0 dld_str_cache 204 2 18 4096B 8 0 process_cache 2180 64 99 225280B 741610 0 exacct_object_cache 28 0 0 0B 0 0 kssl_cache 1320 0 0 0B 0 0 fctl_cache 68 0 0 0B 0 0 tl_cache 244 30 45 12288B 182 0 keysock_1 1 0 0 0B 0 0 spdsock_1 1 0 0 0B 1 0 rds_alloc_cache 60 0 0 0B 0 0 fnode_cache 116 5 25 4096B 53 0 pipe_cache 200 16 54 12288B 167783 0 namefs_inodes_1 1 17 64 64B 59 0 port_cache 52 3 56 4096B 6 0 lnode_cache 16 1 128 4096B 1 0 Hex0xc9dbe364_minor_1 1 0 0 0B 0 0 Hex0xc9d43984_minor_1 1 0 0 0B 0 0 clnt_clts_endpnt_cache 52 0 0 0B 0 0 reference_cache 24 0 0 0B 0 0 reference_history_cache 8 0 0 0B 0 0 zio_cache 552 0 0 0B 0 0 zio_buf_512 512 0 0 0B 0 0 zio_data_buf_512 512 0 0 0B 0 0 zio_buf_1024 1024 0 0 0B 0 0 zio_data_buf_1024 1024 0 0 0B 0 0 zio_buf_1536 1536 0 0 0B 0 0 zio_data_buf_1536 1536 0 0 0B 0 0 zio_buf_2048 2048 0 0 0B 0 0 zio_data_buf_2048 2048 0 0 0B 0 0 zio_buf_2560 2560 0 0 0B 0 0 zio_data_buf_2560 2560 0 0 0B 0 0 zio_buf_3072 3072 0 0 0B 0 0 zio_data_buf_3072 3072 0 0 0B 0 0 zio_buf_3584 3584 0 0 0B 0 0 zio_data_buf_3584 3584 0 0 0B 0 0 zio_buf_4096 4096 0 0 0B 0 0 zio_data_buf_4096 4096 0 0 0B 0 0 zio_buf_5120 5120 0 0 0B 0 0 zio_data_buf_5120 5120 0 0 0B 0 0 zio_buf_6144 6144 0 0 0B 0 0 zio_data_buf_6144 6144 0 0 0B 0 0 zio_buf_7168 7168 0 0 0B 0 0 zio_data_buf_7168 7168 0 0 0B 0 0 zio_buf_8192 8192 0 0 0B 0 0 zio_data_buf_8192 8192 0 0 0B 0 0 zio_buf_10240 10240 0 0 0B 0 0 zio_data_buf_10240 10240 0 0 0B 0 0 zio_buf_12288 12288 0 0 0B 0 0 zio_data_buf_12288 12288 0 0 0B 0 0 zio_buf_14336 14336 0 0 0B 0 0 zio_data_buf_14336 14336 0 0 0B 0 0 zio_buf_16384 16384 0 0 0B 0 0 zio_data_buf_16384 16384 0 0 0B 0 0 zio_buf_20480 20480 0 0 0B 0 0 zio_data_buf_20480 20480 0 0 0B 0 0 zio_buf_24576 24576 0 0 0B 0 0 zio_data_buf_24576 24576 0 0 0B 0 0 zio_buf_28672 28672 0 0 0B 0 0 zio_data_buf_28672 28672 0 0 0B 0 0 zio_buf_32768 32768 0 0 0B 0 0 zio_data_buf_32768 32768 0 0 0B 0 0 zio_buf_36864 36864 0 0 0B 0 0 zio_data_buf_36864 36864 0 0 0B 0 0 zio_buf_40960 40960 0 0 0B 0 0 zio_data_buf_40960 40960 0 0 0B 0 0 zio_buf_45056 45056 0 0 0B 0 0 zio_data_buf_45056 45056 0 0 0B 0 0 zio_buf_49152 49152 0 0 0B 0 0 zio_data_buf_49152 49152 0 0 0B 0 0 zio_buf_53248 53248 0 0 0B 0 0 zio_data_buf_53248 53248 0 0 0B 0 0 zio_buf_57344 57344 0 0 0B 0 0 zio_data_buf_57344 57344 0 0 0B 0 0 zio_buf_61440 61440 0 0 0B 0 0 zio_data_buf_61440 61440 0 0 0B 0 0 zio_buf_65536 65536 0 0 0B 0 0 zio_data_buf_65536 65536 0 0 0B 0 0 zio_buf_69632 69632 0 0 0B 0 0 zio_data_buf_69632 69632 0 0 0B 0 0 zio_buf_73728 73728 0 0 0B 0 0 zio_data_buf_73728 73728 0 0 0B 0 0 zio_buf_77824 77824 0 0 0B 0 0 zio_data_buf_77824 77824 0 0 0B 0 0 zio_buf_81920 81920 0 0 0B 0 0 zio_data_buf_81920 81920 0 0 0B 0 0 zio_buf_86016 86016 0 0 0B 0 0 zio_data_buf_86016 86016 0 0 0B 0 0 zio_buf_90112 90112 0 0 0B 0 0 zio_data_buf_90112 90112 0 0 0B 0 0 zio_buf_94208 94208 0 0 0B 0 0 zio_data_buf_94208 94208 0 0 0B 0 0 zio_buf_98304 98304 0 0 0B 0 0 zio_data_buf_98304 98304 0 0 0B 0 0 zio_buf_102400 102400 0 0 0B 0 0 zio_data_buf_102400 102400 0 0 0B 0 0 zio_buf_106496 106496 0 0 0B 0 0 zio_data_buf_106496 106496 0 0 0B 0 0 zio_buf_110592 110592 0 0 0B 0 0 zio_data_buf_110592 110592 0 0 0B 0 0 zio_buf_114688 114688 0 0 0B 0 0 zio_data_buf_114688 114688 0 0 0B 0 0 zio_buf_118784 118784 0 0 0B 0 0 zio_data_buf_118784 118784 0 0 0B 0 0 zio_buf_122880 122880 0 0 0B 0 0 zio_data_buf_122880 122880 0 0 0B 0 0 zio_buf_126976 126976 0 0 0B 0 0 zio_data_buf_126976 126976 0 0 0B 0 0 zio_buf_131072 131072 0 0 0B 0 0 zio_data_buf_131072 131072 0 0 0B 0 0 dmu_buf_impl_t 168 0 0 0B 0 0 dnode_t 492 0 0 0B 0 0 arc_buf_hdr_t 168 0 0 0B 0 0 arc_buf_t 20 0 0 0B 0 0 zil_lwb_cache 176 0 0 0B 0 0 zfs_znode_cache 132 0 0 0B 0 0 authkern_cache 40 0 0 0B 0 0 authloopback_cache 40 0 0 0B 0 0 authdes_cache_handle 52 0 0 0B 0 0 pty_map 48 0 64 4096B 5 0 sppptun_map 408 0 0 0B 0 0 ------------------------- ------ ------ ------ ---------- --------- ----- Total [hat_memload] 278528B 489675955 0 Total [kmem_msb] 70258688B 34788656 0 Total [kmem_va] 57540608B 149727 0 Total [kmem_default] 51134464B 1736304937 0 Total [kmem_io_256M] 16801792B 12528 0 Total [id32] 4096B 64239 0 Total [bp_map] 0B 602495 0 Total [segkp] 5177344B 4390412 0 Total [umem_np] 0B 1879 0 Total [ip_minor_arena] 64B 3943 0 Total [spdsock] 0B 1 0 Total [namefs_inodes] 64B 59 0 ------------------------- ------ ------ ------ ---------- --------- ----- vmem memory memory memory alloc alloc name in use total import succeed fail ------------------------- ---------- ----------- ---------- --------- ----- heap 188047360B 834666496B 0B 764560 0 vmem_metadata 13807616B 13893632B 13893632B 1690 0 vmem_seg 13500416B 13500416B 13500416B 1648 0 vmem_hash 206336B 208896B 208896B 38 0 vmem_vmem 94080B 115104B 98304B 168 0 heaptext 5226496B 67108864B 0B 160 0 module_text 5421680B 6254592B 5226496B 9244 0 static 0B 0B 0B 0 0 static_alloc 0B 0B 0B 0 0 hat_memload 278528B 278528B 278528B 1017 0 kstat 165432B 176128B 110592B 1024 0 kmem_metadata 72425472B 72482816B 72482816B 54891 0 kmem_msb 70270976B 70270976B 70270976B 54710 0 kmem_cache 133600B 163840B 163840B 451 0 kmem_hash 1980416B 1990656B 1990656B 648 0 kmem_log 7471584B 7475200B 7475200B 12 0 kmem_firewall_va 0B 0B 0B 3 0 kmem_firewall 0B 0B 0B 3 0 mod_sysfile 0B 0B 0B 0 0 kmem_oversize 5655332B 5668864B 5668864B 1338 0 kmem_va 57925632B 57925632B 57925632B 932 0 kmem_default 51138560B 51138560B 51138560B 149739 0 kmem_io_256M 16801792B 16801792B 16801792B 72441 0 kmem_io_16M 0B 0B 0B 0 0 id32 4096B 4096B 4096B 1 0 bp_map 0B 0B 0B 601923 0 segkp 5177344B 5177344B 5177344B 59445 0 umem_np 0B 0B 0B 1832 0 ksyms 1195492B 1421312B 1421312B 9245 0 ctf 902571B 1216512B 1216512B 9235 0 module_data 337409B 2002944B 1695744B 9417 0 logminor_space 21B 262137B 0B 64 0 taskq_id_arena 18B 2147483647B 0B 94 0 rctl_ids 35B 32767B 0B 35 0 zoneid_space 0B 9998B 0B 0 0 taskid_space 26B 999999B 0B 227 0 pool_ids 0B 999998B 0B 0 0 contracts 27B 2147483646B 0B 248 0 ip_minor_arena 64B 262140B 0B 1 0 dls_minor_arena 2B 262143B 0B 8 0 dld_ctl 0B 262143B 0B 0 0 tl_minor_space 30B 262138B 0B 177 0 keysock 0B 262143B 0B 0 0 spdsock 0B 262143B 0B 1 0 namefs_inodes 64B 65536B 0B 1 0 Hex0xc9dbe364_minor 0B 262142B 0B 0 0 Hex0xc9d43984_minor 0B 262142B 0B 0 0 devfsadm_event_channel 1B 101B 0B 1 0 devfsadm_event_channel 1B 2B 0B 1 0 syseventconfd_event_channel 0B 101B 0B 0 0 syseventconfd_event_channel 1B 2B 0B 1 0 syseventd_channel 2B 101B 0B 2 0 syseventd_channel 1B 2B 0B 1 0 logdmux_minor 0B 256B 0B 0 0 ptms_minor 0B 16B 0B 5 0 sppptun_minor 0B 16B 0B 0 0 ------------------------- ---------- ----------- ---------- --------- ----- > ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 44562 174 95% Anon 650 2 1% Exec and libs 14 0 0% Page cache 1 0 0% Free (cachelist) 563 2 1% Free (freelist) 12884902816 8589934592 592697309230268416% Total 46718 182 Physical 46717 182 > [ HIT CTRL - D here ] The machine was unusable. # cd /export/ # ls -lap # # cd /export/ ls -lap fork failed - too many processes # # cd /export/ fork failed - too many processes # # exit Dennis From storycrafter at gmail.com Fri Jan 30 09:18:33 2009 From: storycrafter at gmail.com (Mark Martin) Date: Fri, 30 Jan 2009 11:18:33 -0600 Subject: [emancipation-discuss] Closed header liberation...localedef.h Message-ID: <49833669.1030402@gmail.com> According to the "ON" tab on here: http://www.opensolaris.org/os/about/no_source/ /usr/include/sys/localedef.h is closed with no plans for opening. Would it be possible for someone to investigate the possibility of liberating this file? libast depends on this header (and appears to be the only package in onnv that does). Some discussion regarding this particular file occurred here (http://mail.opensolaris.org/pipermail/install-discuss/2006-May/002645.html) if that helps. Is there any magic in there, or can a suitable, alternate, open source version supplant it?