Re: [osol-discuss] fork1() fails with ENOMEM
On 02/04/11 11:33, Bill Shannon wrote: This isn't really specific to OpenSolaris since it also happens on Solaris 10, but maybe someone here can give me some ideas? I have a java program that is failing because it does something that calls fork1(), which fails with ENOMEM (confirmed using truss): 27010/2: fork1() Err#12 ENOMEM I've used both the 32-bit and 64-bit versions of the JVM. Using the 64-bit version, I see the heap expand to just over 4GB before it forks: 27010/30: brk(0x107DE3D90) = 0 I have almost 160 GB of swap space: $ swap -s total: 806336k bytes allocated + 167872k reserved = 974208k used, 159746184k available It doesn't seem like it can possibly be running out of swap space. What other reasons would cause fork1() to fail with ENOMEM? ___ The vm system is rather fond of using ENOMEM as a generic error bucket. If you have a way of reproducing the problem, a bit of DTrace will quickly turn up the reason. I assume it's only the 32 bit version that is failing to fork, right? - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with Mercurial than with Thunderbird. Civilization advances by extending the number of important operations which we can perform without thinking about them. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Changing Memory Placement Policies through a C program
On 09/21/10 09:12, Kishore Kumar Pusukuri wrote: Hi, I know how to change memory placement policies using mdb. For example, the following is the usage to apply Round Robin policy instead of the default First-Touch policy: $ pfexec mdb -kw ... lgrp_mem_default_policy/W 5 . However, could you tell me how to do the same through a C program, please? Thank you I strongly recommend NOT doing this; instead, alter this behavior on a per-program basis w/ pmadvise or /usr/lib/madv.so.1. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Measuring cost of TLB misses
On 08/20/10 21:21, Kishore Kumar Pusukuri wrote: Hi, I am able to measure TLB miss-rate of a multi-threaded application running on my multi-core AMD Opteron machine by reading performance monitoring event counters using cpustat utility. However, I would like to measure the amount of time spent on TLB misses? Specifically, I am looking a way like the utility trapstat functions. Please share your ideas. TLB miss costs (e.g. page table walk) costs can be estimated by writing code that misses in both cache and tlb, and comparing steady state performance to that of otherwise similar code that misses only in cache. Keep in mind that different size pages may take different amounts of time, and that modern processors do an amazing job of predicting access patterns - so attempts to miss in cache will prob. need some random component. You may find http://icl.cs.utk.edu/projectsfiles/hpcc/RandomAccess/ to be interesting reading... - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community distro
On 07/21/10 15:25, Ian Collins wrote: tches. If Solaris Next is to be IPS based, I really really hope we will see a viable upgrade path. The lack of one is the biggest hurdle to IPS adoption. In general, upgrading from UFS root w/ svr4 packages to ZFS root w/ IPS is a very difficult problem. While we can imagine cases in which we could be successful, there are a host of situations which are not readily addressable. Add to this the fact that most of Sun ^H^H^HOracle's Solaris customers generally do NOT upgrade from one release to the next, because of the reproducibility problem - production machine configurations need to be readily reproducible, and upgrading an existing S10 patched OS is not the best way of doing this. We anticipate developing and sharing migration strategies and tools, but a traditional upgrade in place DVD approach is not likely to occur. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting current kernel thread or CPU Id in a driver
On 07/16/10 08:38, Shank wrote: Hi, Can the function threadp() be used in a kernel driver to get the current kernel thread and the associated CPU Id? Thanks, Shank Yes, threadp returns a pointer to the current thread remember that threads migrate between CPUs w/o warning; any references through t_cpu _must_ be done with calling thread's preemption disabled via kpreempt_disable() (a very fast macro); this will allow your code to safely examine the details of it's current CPU. Otherwise your code _will_ panic when doing dynamic reconfiguration... - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Top Solaris developer flees Oracle- from the reg
On 07/15/10 02:27, Sean . wrote: Was just reading this on the Register myself. This is not good news for the future of Solaris at all never mind OpenSolaris. Many of us very much like Greg... he was a VP here, not a developer, and he has a great opportunity that he wanted to pursue. We wish him luck in his new role @Cisco, and we'll continue building a better Solaris under different (but also familiar) management. Nothing to see here folks; just business in the valley. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] whoo whoo - Oracle's net jumps 25 pct in first full Sun qtr
On 06/24/10 16:09, Gary wrote: Well, you don't make money my shoveling millions into a non-revenue producing product (aka OpenSolaris). But w/o Solaris, a SPARC server is an expensive means of converting electricity to hot air. As many of us have stated, the next release of Solaris will be based on the work done in OpenSolaris. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Slooooowwwww ISCSI copy speeds.
On 04/09/10 12:40, Ron Mexico wrote: I'm running a storage server on sv_134. ISCSI targets were configured with COMSTAR and are initiated on a Sun V480 running Solaris 10. Connection is gigabit ethernet with a crossover cable. Everything is working as it should, but copy speed is slow, around 15-20MB/s. What can I do to speed things up? What filesystem on V480? How is storage configued on your server? How fast can you talk to the storage locally from the server? - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [basic] cmds to discover/report hardware
On 04/01/10 14:17, Harry Putnam wrote: Marion Hakansonhakan...@ohsu.edu writes: shawn.wal...@oracle.com said: Have you checked the output of prtdiag and prtconf -v ? Also smbios, and scanpci (in /usr/bin/X11/ on Solaris-10). Nice... I think most or maybe all that same info is available buy running the program `Device Driver Utility'. However see below for what happens here. Does anyone know the keyboard command to run the: Device Driver Utility Either in the Application/System menu or in some install media there is an icon left for `Device Driver Utility' left on the desktop. When I try to run it from Applications/System menu I get an icon in the taskbar saying `Device Driver Utility' is starting, but then it never appears, and after 30 seconds or so the icon in taskbar disappears but still never see the interface. So how can I start it from the cmdline? ddu as root... - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any news about 2010.3?
On 03/31/10 14:05, Karel Gardas wrote: ZFS data corruption test by researchers: http://www.cs.wisc.edu/wind/Publications/zfs-corruptio n-fast10.pdf Interesting paper. The only problem with it is that ZFS is filesystem and not memory-protection vehicle. If you need memory protection use ECC or more advanced ECC. Karel I find their implicit assumption that filesystem code should expect memory to be flaky to be quite dubious. I am tempted to point out that ZFS doesn't also protect against CPU induced errors or coding errors on the part of the application developer. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to get GUI from servers without video card
On 03/22/10 11:16, Tom Chen wrote: Hello, I have some Sun servers without video card. Is there any way to get GUI? I am using Solaris Express nv133. Tom ssh in w/ -X from a workstation running X and run clients; they will display on your workstation. Alternatively, enable gdm in remote mode and connect in at login on your workstation. -Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] packages required by some extras softwaree not renamed
On 03/08/10 08:30, Bruno Damour wrote: OK I understand, I cannot remove them ! Sorry for the noise Still it would have been nicer to get SunStudioi, Openoffice, etc... depend on the new pkgs, guess time will come soon ;-) Bruno Right now these packages cannot depend on the new names because the folks running release would be unable to install them. Once everyone is running the SAT solver (post build 128), this sort of thing is much easier as the correct unbundled version would be automatically selected; until then we cannot make the latest version of these unbundleds incompatible w/ older releases w/o causing problems. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Some Why?-Questions
Shawn Walker wrote: Craig S. Bell wrote: Let me play devil's advocate: If people have the option to continue using the old package system (with it's action scripting capabilities), then could that slow adoption of the new pkg format? Or is that just the cost of providing compatibility? I think those users will slowly want to move to the newer package system. IPS provides a lot of additional functionality not found in SVR4 (to my knowledge): long list elided Not to mention: * Automated install of transitive closure of dependency graph. * Automated detection of package dependencies part of publication tool chain. * Manifest signing support that allows cryptographic verification of all package contents, and supports addition of signatures to indicate approval for installation in various contexts. * Faceted packages allow package publishers to provide various locales, documentation, developer support as part of single package. Also allows alternate platform support to be elided for minimization purposes; elided portions of packages are easily restored. * Fast enough at generation of packages and update to allow developers to use native packaging rather than workarounds (bfu Install); this should significantly improve packaging quality and reduce errors. * Elimination of alternative patching mechanism means no going back to repatch systems after installation of new packages; added packages are always correct for current revision level of system. * Reduction of change stream development costs (no patch scripts to write!) offers easier opportunity to deliver tailored change streams to Sun customers. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Cannot load driver
Joerg Schilling wrote: joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote: joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote: After a long time, I tried again to load/run an own Solaris driver and failed with the following messages: Sep 17 15:24:44 opt genunix: [ID 286029 kern.notice] relocation error: R_AMD64_32: Sep 17 15:24:44 opt genunix: [ID 720415 kern.notice] file /kernel/drv/amd64/scg: Sep 17 15:24:44 opt genunix: [ID 370954 kern.notice] symbol : I found the solution. It works after adding -fPIC. But why is there no problem with the solaris drivers? Mmm this still was not the right solution as the kernel linker now linked the variable scsi_options which is physically in genunix at 0xfbc8a1f0 to address 0xf3b2733b inside my driver. As mentioned, the real location of scsi_options is 0xfbc8a1f0 I I checked correctly, this seems to be nowhere in the kernel mappings: BASELIMIT SIZE NAME fe00 fe01180011800 kpmseg ff00 ff0007a0 7a0 kvalloc ff0007a0 ff0087a0 8000 kpseg ff0087a0 ff018720 ff80 kzioseg ff01c720 ff01cb20 400 kmapseg ff01cb20 c000 fdf4e0 kvseg c000 fb7fb000 3b7fb000 kvseg_core fb80 fbd31000 531000 ktextseg ff80 ffc0 40 kdebugseg Jörg Are you compiling w/ -xmodel=kernel ? - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Cannot load driver
Joerg Schilling wrote: Bart Smaalders bart.smaald...@sun.com wrote: Mmm this still was not the right solution as the kernel linker now linked the variable scsi_options which is physically in genunix at 0xfbc8a1f0 to address 0xf3b2733b inside my driver. As mentioned, the real location of scsi_options is 0xfbc8a1f0 I I checked correctly, this seems to be nowhere in the kernel mappings: BASELIMIT SIZE NAME fe00 fe01180011800 kpmseg ff00 ff0007a0 7a0 kvalloc ff0007a0 ff0087a0 8000 kpseg ff0087a0 ff018720 ff80 kzioseg ff01c720 ff01cb20 400 kmapseg ff01cb20 c000 fdf4e0 kvseg c000 fb7fb000 3b7fb000 kvseg_core fb80 fbd31000 531000 ktextseg ff80 ffc0 40 kdebugseg Thank you for yout hint. Are you compiling w/ -xmodel=kernel ? I compile with -Wu,-xmodel=kernel is there a difference to using -xmodel=kernel directly? Jörg Well, they seem to produce the same disassembler output but different section headers. Try it and see. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to move the os to anther disk (no mirroring)
stephen bond wrote: I partitioned as Harry described and still get the overlap error. I have: zpool will complain, because the backup partition overlaps all the others. Use -f. http://bugs.opensolaris.org/view_bug.do?bug_id=6419310 - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Performance issues
Paul Nichols wrote: The latest stable release is much improved from a GUI perspective. However, this version is really slow. Even with no GUI, the performance has really taken a hit! Any ideas on how to speed up the latest release to acceptable performance levels? The OS is about 2 times slower than RedHat OS now. You're going to need to give us a hint as to what you're running on and what you feel is slow. This could be anything; in particular some ATI chipsets have suffered from poor performance OOTB, but it could almost be anything given no other data point than slow. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Performance issues
Paul Nichols wrote: Ok here are the hardware specs I can put the info on the message, but basically it should fly!! Machine: Processor: AMD Athlon x264 5400+ RAM: 8 GIG DDR2 PC6400 Graphics (although this is a server): 128meg NVidia GeForce 4 Microstar MB Intel Eth0, eth1 100 Pro Server HardDrive: (1) WD 7200 RPM, 500 GB (2) WB 7200 RPM, 500 GB Should be noted RedHat EA 5 FLIES on this machine. OK, that's the machine specs, and indeed, it should be fast on everything except running graphics; I think your video card is only supported on down rev versions of the nvidia driver. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Performance issues
Paul Nichols wrote: Really do not care about the grapihics performance. This is a server. However, what I do care about is performance. The earlier version of Open Solaris for X64, was quite a bit faster on the same hardware. My point was, yes the graphics and GUI look more polished in this release, but the kernel has changed enough to cause the overall performance has taken a serious hit. I wondered why? I still have no idea what performance problems you're having. Did you measure completion time of some benchmark? Or is this perception of time needed to complete a command? Or what? How do you know this is the kernel? - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [desktop-discuss] Poor interactive performance under heavy system load
Alan Coopersmith wrote: Joerg Schilling wrote: Another issue: Xsun did use mmap() to allocate bigger parts of memory in the X server. If big memory leaking program like netscape died in former times, Xsun did shrink. Today, we have firefox that itself allocates less memory than before but rather forxes X to allocate more memory and Xorg is malloc() based and this does not shrink when fireforx dies... We had to turn down Xsun's use of mmap() because it caused performance problems when programs like Netscape or the GNOME desktop had allocated hundreds of pixmaps per session, and you had dozens of sessions running on a Sun Ray server leading to TLB thrashing for all those new page mapping entries, especially on the UltraSPARC CPU's with small TLBs. There were also performance issues with pixmap allocation deallocation becoming much more expensive, since mmap/mmunmap are far more expensive calls than malloc/free. (See for instance, the GNOME stock ticker issue described in the original DTrace Usenix paper, and http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4757131 ) Even so, we've looked at porting those changes to Xorg before, and I released the Xsun code to Roland at one point when he volunteered to port it, but have never gotten it done. What is needed is allocation technology that doesn't muck w/ the process address space because that's expensive for long-running processes that have migrated to every cpu on the box; you end up cross-calling lots of other cpus, and if your clients do stupid allocation behaviors the cross call rate goes through the roof. On the other hand, if the pages are no longer interesting, writing them out to swap and paging them back in isn't very interesting either. What may be a useful experiment is using madvise(caddr_t addr, size_t len, MADV_FREE) on large deallocated pixmaps: MADV_FREE Tell the kernel that contents in the specified address range are no longer important and the range will be overwritten. When there is demand for memory, the system will free pages associated with the specified address range. In this instance, the next time a page in the address range is referenced, it will contain all zeroes. Otherwise, it will contain the data that was there prior to the MADV_FREE call. References made to the address range will not make the system read from backing store (swap space) until the page is modified again. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [desktop-discuss] Poor interactive performance under heavy system load
Marion Hakanson wrote: erva...@gmail.com said: When the system is largly idle the gnome desktop feels fast and snappy, and interaction is very immediate. However, when I start a heavy background process (for instance a maven build of a large Java application), CPU utilization shoots to 100% on both CPU cores (which is good!), but my whole desktop becomes sluggish, even mouse movement becomes erratic. It's not necessarily CPU contention that's making things slow. My systems behave this way when RAM is short; Xorg or window-manager get paged out, and things get jerky/erratic. Our original prototype for the IA class back in the early 90s (!) did influence memory allocation, but this wasn't really tenable in a scheduling class. It did work very well, however. http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/evans.txt True control of RAM given to various processes awaits the VM2.0 project, which is currently underway. Attempts to correctly schedule memory use w/ the current VM system have been unsuccessful despite rather valiant efforts. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [desktop-discuss] Poor interactive performance under heavy system load
Ignacio Marambio Catán wrote: VM2.0? it's not the first time i've heard something like that, is there any information about it? http://osdir.com/ml/os.solaris.opensolaris.performance/2008-01/msg00024.html - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Phoronix Linux vs OpenSolaris benchmark
The default compilation mode of gcc and cc in OpenSolaris is still 32 bit; since Opensolaris combines both 32 and 64 bit architectures it was decided (during S10 development in 2004) to ship the compilers producing binaries that would run anywhere. For OpenSolaris, choosing 64 bit binaries by default is equivalent to choosing to use machine-specific code generation options by default that would confine the use of the generated binaries to the same machine type as the build machine - nice for benchmarking, a little surprising if you're building applications for others to use. Several individuals have discussed this with the Phoronix folks, from what I understand; apparently they feel this is a valid way to benchmark operating systems. Were this to become commonplace, I would expect the need for benchmark supremacy to lead to the selection by default of every available non-portable optimization - not very useful for anyone developing or sharing binaries rather than shipping source. One has only to look at the introduction (incorrectly, initially) of a cached version of getpid() in some distros in order to beat the well-known system call overhead measurements in LMbench a few years ago; this optimization has no practical purpose as most binaries make very few calls to getpid(), but was nonetheless shipped in several distros as benchmarketing ammunition. Opensolaris treats 32 and 64 bit x86 machines as being the same architecture, Linux does not but provides some optional compatibility components to permit running some 32bit binaries on 64 bit machines. So, if the goal of the exercise is to determine on which platform a naive compilation approach provides better performance, then this benchmark is correctly coded. If that was not the goal, then the benchmark is badly designed, because that is what it is measuring. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [indiana-discuss] [perf-discuss] Memory leak somewhere, maybe in libc (libc_hwcap2.so.1 / SXCE b105 x64) ?
Martin Bochnig wrote: Both my version of wget shall have a bug and my version of top? Seriously, how likely is this? Isn't it more likely that there is a problem in a shared library that both happen to use? If this is reproducible, could you employ libumem to get an idea of where the leaks are occuring? % export UMEM_DEBUG=default % LD_PRELOAD=libumem.so.1 wget . after a while, use gcore $WGETPID to generate a core from another window. Attach mdb and run ::findleaks: : ba...@cyber[9]; mdb /usr/bin/wget core.19356 Loading modules: [ libumem.so.1 ld.so.1 ] ::findleaks CACHE LEAKED BUFCTL CALLER 080b1510 6 080f1218 checking_malloc+0x11 080a9290 1 080c6930 libc_hwcap2.so.1`strdup+0x26 080a9290 1 080c69a8 libc_hwcap2.so.1`strdup+0x26 Total 8 buffers, 3872 bytes If no leaks are found, allocated memory is still reachable so use ::umausers to find out the pigs: ::umausers 101520 bytes for 1269 allocations with data size 80: libumem.so.1`umem_cache_alloc_debug+0x144 libumem.so.1`umem_cache_alloc+0x19a libumem.so.1`umem_alloc+0xcd libumem.so.1`malloc+0x2a libc_hwcap2.so.1`strdup+0x26 checking_strdup+0xf string_set_add+0x23 retrieve_tree+0x37f main+0x5ed _start+0x7d 100880 bytes for 1261 allocations with data size 80: libumem.so.1`umem_cache_alloc_debug+0x144 libumem.so.1`umem_cache_alloc+0x19a libumem.so.1`umem_alloc+0xcd libumem.so.1`malloc+0x2a libc_hwcap2.so.1`strdup+0x26 checking_strdup+0xf retrieve_tree+0x343 main+0x5ed _start+0x7d ... - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] isaexec?
I would say there are many systems 32-bit only (and there is some probability even 32-bit SPARC kernel will return). This is absolutely not the case. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [indiana-discuss] why gnu chmod in os2008.11?
Nicolas Williams wrote: On Fri, Jan 16, 2009 at 03:26:20PM -0600, Shawn Walker wrote: tcsh is not a core Solaris package and media is not of an infinite size. Software has to be selected to fit on the core media based on certain goals. Everyone has their own favourite software that probably isn't installed by default. I don't understand why pfexec pkg install SUNWtcsh isn't sufficient. Can't it be in entire? ___ It is. Entire is not a set of require dependencies, it is a set of incorporate dependencies - they are optional, but if present the specified version is required. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [indiana-discuss] why gnu chmod in os2008.11?
Nicolas Williams wrote: If the upstream community won't take patches to make ls(1) and chmod(1) support ZFS/NFSv4 ACLs then we can always: - re-implement GNU options into /bin/ls and /bin/chmod - for chmod this is probably easy since the options that GNU chmod has that Solaris chmod doesn't are few and simple: Everyone who is contributing to this email thread is encouraged to make their opinions known via putbacks/pushes rather than email. If the Solaris commands become a superset of the Gnu ones, then that position becomes a fait accompli. -= Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [indiana-discuss] why gnu chmod in os2008.11?
Mike Meyer wrote: On Fri, 16 Jan 2009 17:42:00 -0500 (EST) Dennis Clarke dcla...@blastwave.org wrote: If the Solaris commands become a superset of the Gnu ones, then that position becomes a fait accompli. Thus avoiding the entire question of whether or not that's the best - or even a desirable - goal. There are lots of proposals for someone else to do work, but few volunteers stepping up to the plate. I'm suggesting that those who argue in favor of extensive changes to the existing Solaris commands can demonstrate their commitment and interest by helping out. It's not like we have a large team here at Sun tasked w/ this (or many other) projects. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How Best to Handle
Ali Bahrami wrote: Daniel Templeton wrote: snip 2) Offer a single package that includes all the tuned libraries under a sub-directory and provide a way to switch among them, such as the modules command (which is on our list of things to port). This sounds like a pretty good match for hardware capabilities. You can produce multiple versions of your libraries, each tagged with their specific hardware requirements, and then produce a shared object filter on top of them. The runtime linker will select the best library to actually load at runtime, based on your end user's hardware. Here's a blog that Rod wrote about the subject of object filters: http://blogs.sun.com/rie/entry/shared_object_filters and the Solaris Linker and Libraries guide has some information on the subject also: http://docs.sun.com/app/docs/doc/817-1984 This will work, as long as the options you want to use correspond to the defined hardware capability bits. This is the right way to proceed if you can avoid generating libraries tuned for cache sizes, pipeline peculiarities, etc. If you must do the latter, you'll need to invent your own mechanisms, but keep in mind that new CPUs are added all the time so any CPU-specific tunings have a very limited shelf-life. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How Best to Handle
UNIX admin wrote: The question on the table is how we should go about providing optimized libraries for all reasonable chip sets. Have you looked into isaexec(3C) (/usr/lib/isaexec)? The applicability of isaexec to libraries is limited. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] poweroff high CPU burn?
Rocky wrote: Unfortunately the power-off command (init 5) only works in about 50% of cases on my snv_82 machine. I found that some of the power-saving features (HDD spin-down) cause some conflicts. Unfortunately in some cases when init 5 has succeeded in taking the ^ did you leave out not computers power off, the system is left in a maximum burn condition; i.e. all disks running and CPU running flat-out; this hits maximum heat generation in my system. Any chance the CPU could be halted after the failed power-off? Ideally the power-off would work though. It would be possible to make more progress with this problem if you would tell everyone: 1) what sort of system you're running 2) where the shutdown is hanging, preferably w/ a stack trace. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] how to disable sun cc optimization partly in program?
?? TaoJie wrote:
Dear all:
My platform is:
Intel Pentium 4 CPU
OpenSolaris B74, built by myself
Sun Studio 11
In my program, I use asm(rdtsc) to measure the time cost between two rdtsc.
for example:
int some_func(...)
{
long long time1, time2;
int i = 3198, j = 324;
asm volatile(rdtsc : =A (time1));
i = i + j * i / j;
asm volatile(rdtsc : =A (time2))
return i;
}
int main(...)
{
some_func();
}
When I compile this program using cc example.c and disasmble a.out
by dis, the program logic is ok. The output is
some_func()
main+0x36: 0f 31 rdtsc
main+0x38: 89 45 f4 movl %eax,-0xc(%ebp)
main+0x3b: 89 55 f8 movl %edx,-0x8(%ebp)
main+0x3e: 8b 45 e8 movl -0x18(%ebp),%eax
main+0x41: 03 45 e4 addl -0x1c(%ebp),%eax
main+0x44: 89 45 e8 movl %eax,-0x18(%ebp)
main+0x47: 8b 45 e8 movl -0x18(%ebp),%eax
main+0x4a: 0f af 45 e4imull -0x1c(%ebp),%eax
main+0x4e: 89 45 e8 movl %eax,-0x18(%ebp)
main+0x51: 8b 45 e8 movl -0x18(%ebp),%eax
main+0x54: 99 cltd
main+0x55: f7 7d e4 idivl -0x1c(%ebp)
main+0x58: 8b d0 movl %eax,%edx
main+0x5a: 89 55 e8 movl %edx,-0x18(%ebp)
main+0x5d: 0f 31 rdtsc
main+0x5f: 89 45 ec movl %eax,-0x14(%ebp)
main+0x62: 89 55 f0 movl %edx,-0x10(%ebp)
When I compile this program using cc -xO5, the dis output is
some_func()
main+0x7: 0f 31 rdtsc
main+0x9: 89 45 e8 movl %eax,-0x18(%ebp)
main+0xc: 89 55 ec movl %edx,-0x14(%ebp)
main+0xf: 0f 31 rdtsc
main+0x11: 89 45 f0 movl %eax,-0x10(%ebp)
main+0x14: 89 55 f4 movl %edx,-0xc(%ebp)
main+0x17: 8b 5d f0 movl -0x10(%ebp),%ebx
main+0x1a: 8b 45 f4 movl -0xc(%ebp),%eax
main+0x1d: 8b 4d e8 movl -0x18(%ebp),%ecx
main+0x20: 8b 55 ec movl -0x14(%ebp),%edx
main+0x23: 2b d9 subl %ecx,%ebx
main+0x25: 1b c2 sbbl %edx,%eax
main+0x27: 89 5d e0 movl %ebx,-0x20(%ebp)
main+0x2a: 89 45 e4 movl %eax,-0x1c(%ebp)
Now the program logic is wrong! sun cc thinks rdtscs are irrelative
with the other parts in some_func, and then it advances the second
asm(rdtsc)!
In this case, I can't measure the time cost.
Then how can I stop sun cc optimization partly between these two asm
statements when using -xO5 optimization to the whole program?
I mean the second rdtsc should be put after the statement i = i + j *
i / j strictly. (though I know the instructions will be executed in
x86 cpu out-of-order, and the result may not be very precise, but it
still works)
Any good ideas?
TIA
Regards,
TJ
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
You're going to be very frustrated with this approach because:
1) rdtsc is not a synchronizing instruction; the cpu may perform
the load earlier than you think it does.
2) you'll need to bind your program to a cpu as tsc counters are not
the same at boot.
My suggestion is to repeat the activity a sufficient number of times
such that you can afford to use gethrtime() to measure the time
interval. This is the approach we took w/ libmicro (see performance
community) and has worked reasonably well.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] So... when is Sun going to start offering SXCE/SXDE support contracts?
Glen Wiley wrote: Bart, You or Tim had mentioned the idea of being able to support checkpoints of some kind which would let more rigid environments take advantage of some of the more useful features with reduced risk. Do you see motion in that direction? With the new packaging/software repository, we'll be able to update the software on a machine by downloading the difference between where the target machine and the desired end state. Using ZFS root, this will be completely reversible. Once the new packaging system is part of our mainline development environment, it would be possible to offer a release train containing periodic large scale change, interspersed with small scale critical fixes. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] So... when is Sun going to start offering SXCE/SXDE support contracts?
glen wiley wrote: Bart, Thanks - that sounds perfect. Do I understand then that Sun would offer a structured (whatever that means) support mechanism for specific stops on the release train? I would expect Sun to do that. What actually ends up happening is of course to be seen :-). We are building the technology to make this possible. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] So... when is Sun going to start offering SXCE/SXDE support contracts?
Alan DuBoff wrote: On Thu, 2 Aug 2007, Bart Smaalders wrote: With the new packaging/software repository, we'll be able to update the software on a machine by downloading the difference between where the target machine and the desired end state. Using ZFS root, this will be completely reversible. Once the new packaging system is part of our mainline development environment, it would be possible to offer a release train containing periodic large scale change, interspersed with small scale critical fixes. Would that be file based? Or would that use the internal checksums on the blocks? Just curious. The likely outcome is that the change is file based, with file equivalence determined by a file-type specific comparison/hash. This allows us to handle cases where the file is alway different, but semantically the same. Jar archives are a typical example here. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] So... when is Sun going to start offering SXCE/SXDE support contracts?
Alan DuBoff wrote: On Thu, 2 Aug 2007, Bart Smaalders wrote: The likely outcome is that the change is file based, with file equivalence determined by a file-type specific comparison/hash. This allows us to handle cases where the file is alway different, but semantically the same. Jar archives are a typical example here. You know, I was thinking about this after I sent the message, and *think* that snapshots would use the checksums under the covers, so it might be possible to incorporate snapshots to do a very similar thing as at the block level. I was curious as I was talking last week with Olaf Manczak, and he had been tossing around the idea of using the checksums to accomplish a similar thing. So, in the above scenario with Jar files, are you saying that they have more than one file with the same name that would get installed depending on the system? If so, is that done for optimization? -- Alan DuBoff - Solaris x86 IHV/OEM Group two jars that have the same content may have been created at different times; from a functionality standpoint they are the same but they have an internal timestamp that is different. - -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] So... when is Sun going to start offering SXCE/SXDE support contracts?
Ian Collins wrote: Brian Gupta wrote: It would make it easier for some of us to deploy OpenSolaris. How can Sun support something that changes every couple of weeks and doesn't support patching? I suppose they could provide a help line with a recorded message please upgrade the the latest release :) Ian Well, let's see what we can do w/ a new packaging system that lets us upgrade Solaris easily see my latest blog entry on dim sum patching. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Rationale for 64K mmap alignment?
David McDaniel wrote: Wondering if anyone knows the reason mmap always returns space 64K aligned on 32 bit sparc apps. If many small files are mmap'd, lots of address space gets eaten up. Also, can it be changed via a knob anywhere? The ELF alignment requirement for 32bit executables is 64k. Since there was no MAP_ALIGN flag for mmap, the default alignment returned from mmap was made to be the same as the ABI-required executable requirement. Have you tried passing a 8K alignment requirement to mmap? I believe it defaults to 64k I'm not sure will do what you want, but there's a good chance. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] is audiocs being power managed?
Richard L. Hamilton wrote: I've been hearing static-like sounds from my speakers every so often when the audio should have been inactive; I'm thinking that it's being power-managed somehow. (sun blade 2000, audiocs device, build 66) I just added the line device-thresholds /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL PROTECTED],20 always-on to /etc/power.conf and ran pmconfig; there was a bit of static when I did that, but so far, none since (although it hasn't been very long yet). The prtconf -v output for that device includes Driver properties: name='pm-components' type=string items=3 dev=none value='NAME=audiocs audio device' + '0=off' + '1=on' leading me to think that if nothing else, it's turned off and on. Having an inactive audio device power off may save me a few cents a year, but the unexpected noises are annoying. Am I on the right track? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org If you're running a debug kernel, the audio driver will get unloaded if no process has it open. This can happen if you're using CDE... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris Nevada and sparcv8
Steven Stallion wrote: [EMAIL PROTECTED] wrote: ... Actually, no. ZFS works best with 64bit CPUs (and I can testify to that with issues I've had on i386 PCs), so getting it to run on SPARCv8 systems is goint to mean a compromise in performance for ZFS vs what you'll see with UltraSPARC and amd64. Darren No disagreement here, however we work with what we have ;) How degraded would the performance be using a framework friendly HBA? Essentially, anything over 20M/s would be an improvement over the currently installed OS. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org The big issue with sparcv8 chips and ZFS would be memory bandwidth I don't remember the figures off the top of my head, but I do remember UltraSPARC I to be a very significant jump in performance when it came to moving large blocks of data from place to place. ZFS will touch every byte in order to do checksums. A quick dive into google indicates that SparcStation 10s did about 20MB/sec doing bcopy, and UltraSparc I about 170MB/sec. Basically, you'll find an SS10 violates the assumptions upon which ZFS was designed - fast cpus, lots of memory bandwidth. My guess is that you would be quite lucky to get anywhere close to 20MB/sec... When new CPUs with lower power consumption are 50x faster, it doesn't make much sense to stick w/ the old. Keep in mind that the SS10 was introduced in the middle of 1992 - it's 15 years old as of last month. It was instantly obsolete in 1995, when Sun shipped the UltraSPARC 1. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: valgrind for solaris?
UNIX admin wrote: Regarding the former, I see no reason not to include valgrind in the Solaris multiverse, once the new packaging system kicks in. Which new packaging system? Several of us are actively discussing a new packaging system for Solaris... we're still figuring out the shape of the elephant, but it feels like it might have legs. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: valgrind for solaris?
Ignacio Marambio Catán wrote: On 6/12/07, Bart Smaalders [EMAIL PROTECTED] wrote: UNIX admin wrote: Regarding the former, I see no reason not to include valgrind in the Solaris multiverse, once the new packaging system kicks in. Which new packaging system? Several of us are actively discussing a new packaging system for Solaris... we're still figuring out the shape of the elephant, but it feels like it might have legs. Backwards compatible i assume, is there any pre-pre-pre-draft about it? nacho Not yet the idea is likely to create a new packaging system but leave the existing one in place for legacy applications/packages. We're working on requirements, etc. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: valgrind for solaris?
Shawn Walker wrote: On 12/06/07, Bart Smaalders [EMAIL PROTECTED] wrote: Not yet the idea is likely to create a new packaging system but leave the existing one in place for legacy applications/packages. We're working on requirements, etc. It'd be great to see that discussion happen on the install or other appropriate mailing list. That's going to happen; we're trying to understand enough of the problem space so the discussion can be fact based :-). - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: valgrind for solaris?
UNIX admin wrote: Not yet the idea is likely to create a new packaging system but leave the existing one in place for legacy applications/packages. We're working on requirements, etc. Where do I join? Packaging is something very important and dear to me. We're going to put a project proposal together. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What's the best TERM setting when working remotely from a Linux system?
Alex Bennee wrote: Hi, I've never been able to find the correct TERM magic to fix my remote terminal. My principle box is a Linux one with a gnome-terminal with which I ssh over to my Solaris box. The default term setting is xterm but this seems to have problems with re-drawing long lines when I edit previous commands in bash. I end up having to go to the start and use the arrow keys to go over the whole command to see what it displays. I've experimented with various other settings for TERM but the best I've managed is to disable the multi-line display in favour of a scrolling single line. Most of these settings tend to cause less to complain about the terminal not being fully functional. Any ideas or suggestions? The only other magic I can thing may be affecting things is my prompt variable and COLRTERM: PS1=\A [EMAIL PROTECTED] [\W] COLORTERM=gnome-terminal This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org caveat - I'm no expert at this stuff Perhaps the easiest thing to do is to ssh -X over and then to remote display the gnome-terminal. Remote display in the manner you describe works fine between two Solaris machines (of different architectures) running gnome-terminal. Note that Solaris doesn't use /etc/termcap, it uses terminfo. If Linux is using /etc/termcap, you may wish to use captoinfo(1M) to convert the Linux machine's /etc/termcap entry to a new terminfo entry and use that when logging in remotely. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_64a says 768MB RAM to play ?
Dennis Clarke wrote: I was shocked to see that my old old trusty HP Kayak XU tower was finally at a point where it can not install Solaris. I have run Solaris 8 and 9 and 10 on it for years and years. It has two DVD burners and three SCSI controllers, terribly simple graphics and no sound. It just works.[1] I burned the snv_64a DVD and discovered that the 512MB of RAM was no longer reasonable for the installer. I'm shocked. Am I to understand that the x86 miniroot on there will fill up all of my RAM and still need more? Gee. Time for a new machine I guess but this one won't die and it runs Solaris 10 just fine. So then, whats the minimal system spec that Solaris 11 is shooting for? I'll guess 1GB RAM, 18GB of disk, 100Mb/sec ethernet and a 1GHz proc. As has been repeatedly discussed here, the current memory requirements of the developer release installer are an artifact of its hurried implementation (eg 2 jvms). This will not continue to be the case. I think you'll find the system to be quite usable w/ 512MB, but heavy users will want more to prevent paging... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris 10 error VOLTAGE_SENSOR
Anne wrote: Hi All I received this error: VOLTAGE_SENSOR at MB/V_+3V3STBY has exceeded low soft shutdown threshold It immediately shuts down my entire system. I looked at Sun.com for answers. Everything they threw at me, hasn't proved fruitful. Any ideas on how to fix this error? Perhaps you could tell us what kind of machine this is and what version of Solaris you're running? I found 3 hits on sun.com web pages using google try this link: http://www.sun.com/products-n-solutions/hardware/docs/pdf/819-7981-11.pdf - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Packaging and package format modernization goals. (Top Priority)
Brian Gupta wrote: Going back to my initial motivation to get involved with OpenSolaris, and trying to find a common thread from conversations both within and without Opensolaris.org, it seems that the biggest area that needs addressing is the lack of a modern comprehensive packaging and distribution standard for OpenSolaris/Solaris. (This needs to be made a top priority) In order to do that we need a set of common goals, defining what we expect out of our modern packaging standard. I have started with a list below. Let's work from there and see if we can't all agree on what is ideal. * Must support vertical dependency trees (To ease in installation.) E.g. packaging tools should install transitive closure of dependency graph. * Dependencies must support the concept of X version or above. * Must support the concepts of bundles and horizontal dependencies. This is a concept where a group of packages need to be installed together, or not at all. * Must be as fine grained as possible this is irrespective of packaging system, aside from constraints engendered by poor technology... * Must support multiple versions of individual packages this would need to be in separate locations, obviously. * Must support uninstallation that will check and warn about all dependents * Must support source packages. (With all dependency info, allowing an install or upgrade via source). Why? Does this make sense for large environments like a kernel? Wouldn't it make more sense to point someone at an hg server? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Initial Presto prototype bits available.
Norm Jacobs wrote: The Solaris Printing team and the Desktop team have been working together to improve the printing experience for Solaris users. One of the areas that is being addressed is printing management. A few months ago, the Presto project was initiated on OpenSolaris with the aim of easing printing configuration management by either making it completely automated or as hands off as possible. A Flash demo of Presto at work can be found at http://www.opensolaris.org/os/project/presto/Movie/. You can download and install a copy of the prototype bits from http://www.opensolaris.org/os/project/presto/Prototype/. The initial prototype that is *very* rough. It only includes the very basics... * Local USB printer hotplug support (in Nevada build 53 and later) * OSPM Desktop applet and preferences capplet * Network print queue discovery and automation We are moving forward to include more features like... * Network printer hotplug support * Expanded OSPM capabilities (Queue management, job management, ...) * Network print queue advertisement * Print service event notification (errors, completion, ...) For more information you can go to the Presto project page at http://www.opensolaris.org/os/project/presto/ As always, comments, question, and participation is not just welcome, but encouraged. Very cool, folks. I like the automatic config, and I really like the error messages for disconnected hardware after I got bit by that late one night. I'm looking forward to seeing this in OpenSolaris. I think the automatic discovery methods (Rendezvous, SLP, SMB printing, etc) will really make nomadic users a lot happier. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Bittorrent client for Solaris
So Given the difficulties of incorporating the swt libraries needed to make Azureus work on Solaris, what other BitTorrent client should Solaris incorporate? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: Sensor Abstraction Layer for the Solaris Fault Manager
cindi wrote: The Project This project proposes extensions to the fault management architecture (FMA) to support a sensor abstraction layer for the collection and analysis of sensor based telemetry that can be used in fault and resource management. The Problem How do we manage raw telemetry data kept, maintained and exported by disparate sources for the purposes of fault, resource management and budgeting? Today, there are a number of sensor collection mechanisms exported by the hardware and software. For the most part, the information they export is hap-haphazardly presented and accessed according to ad-hoc operating system interfaces, per-platform methods or per-subsystem industry standards (SMBus, SMART and IPMI). Using this data for fault or resource management is clumsy and typically requires low-level system knowledge baked into higher-level management applications. Key Objectives As part of an overall sensor abstraction layer based on our current fault management architecture, we can solve the problem described in section 1.1 and provide a better understanding of the overall health and usage of a system through more sophisticated diagnosis technologies and fine-grained observability of sensor data via common access methods. A sensor abstraction layer must posses: 1. the ability to alert the administrator to conditions observed by platform sensors that may impact the operational state of the platform. 2. the ability to alert the administrator to conditions that resolve themselves as observed by platform sensors. 3. the ability to watch one or more sensors and correlate the data for predictive fault analysis or resource management. 4. the ability to continuously record sensor data and retrieve it from systems for offline analysis, future system design or development of more advanced diagnosis algorithms. 5. the ability for administrators and service personnel to manually inspect sensor values without having to understand the exact implementation (e.g. IPMI or SMBus). 6. the ability to connect sensor data to higher-level diagnosis (e.g. SMART disk data to SCSI and ZFS diagnosis engines) 7. the ability to understand and observe performance and power budgets based on raw sensor data. Cindi +1 Can we add the concept of software sensors to this? Eg could a web server offer #requests satisfied, for example? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris Express on the new Mx000 series
Chris Steinke wrote: Anyone here from Sun have Solaris Express working on the new Mx000 series systems yet? Yes. Putbacks go into Solaris Nevada first; support for these machines started being added around build 38, about this time last year. I'd be curious to hear about experiences with it. Mainly because I've heard that Fujitsu systems had some compatibility issues with Solaris Express and you needed to use Fujitsu's version of Solaris. This may have been true (I don't know) with previous Fujitsu gear; it's certainly not the case for these machines. The new Mx000 series appear to be using the Fujitsu M64 processors. The M series I'm logged into right now reports Sun Microsystems sun4u Sun SPARC Enterprise M8000 Server and is running nightly as of a few days ago... it looks like every other big fast box, although chip speeds are a little higher than I've seen on SPARC before: % psrinfo -vp The physical processor has 2 cores and 4 virtual processors (0-3) The core has 2 virtual processors (0 1) The core has 2 virtual processors (2 3) SPARC64-VI (portid 1024 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (8-11) The core has 2 virtual processors (8 9) The core has 2 virtual processors (10 11) SPARC64-VI (portid 1032 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (16-19) The core has 2 virtual processors (16 17) The core has 2 virtual processors (18 19) SPARC64-VI (portid 1040 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (24-27) The core has 2 virtual processors (24 25) The core has 2 virtual processors (26 27) SPARC64-VI (portid 1048 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (32-35) The core has 2 virtual processors (32 33) The core has 2 virtual processors (34 35) SPARC64-VI (portid 1056 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (40-43) The core has 2 virtual processors (40 41) The core has 2 virtual processors (42 43) SPARC64-VI (portid 1064 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (48-51) The core has 2 virtual processors (48 49) The core has 2 virtual processors (50 51) SPARC64-VI (portid 1072 impl 0x6 ver 0x92 clock 2400 MHz) The physical processor has 2 cores and 4 virtual processors (56-59) The core has 2 virtual processors (56 57) The core has 2 virtual processors (58 59) SPARC64-VI (portid 1080 impl 0x6 ver 0x92 clock 2400 MHz) % Now to scam some disk space; I think I've found my private SPARC build machine :-). - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?
Peter Tribble wrote: On 4/11/07, John Plocher [EMAIL PROTECTED] wrote: Or, looking at it the other way, packages map to the output of an independent, distributed development team. They are the ultimate consolidation boundary - everything within a package is delivered together as a unit and the package is expected to always be self-consistent. So what you're saying - explicitly - is that packages are only a meaningful abstraction for the development process and aren't designed to deliver useful units of functionality for customers? And yet it's us administrators who have to deal with the packaging system, while the development process is based around features and code. I'm arguing that packaging should be based on the functional needs of users/customers rather than being an artifact of the development process. Packages should represent a minimization boundary; e.g. they are either installed or not installed depending on the proposed use of the system. Solaris has areas where packages are too fine-grained, it also has areas where the packages are much too large to be useful in this fashion. Package refactorization is a significant amount of work, and would be greatly aided by better tools. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?
Darren J Moffat wrote: Bart Smaalders wrote: Packages should represent a minimization boundary; e.g. they are either installed or not installed depending on the proposed use of the system. Solaris has areas where packages are too fine-grained, it also has areas where the packages are much too large to be useful in this fashion. and also has multiple packages for somethings where the minimization boundary would dictate only one due to how diskless clients and sparse root zones do sharing of /usr and how the installers provide for that. That's a broken artifact of the current implementation :-(. Note that zones directory sharing breaks packaging in new and wonderful ways. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?
I. Szczesniak wrote: Ask yourself: What will happen if a system script encounters a file name with multibyte characters. Well, mostly they just work. Sometimes there are bugs, just as there are bugs when filenames have spaces in them. Do you have a specific example of a problem? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list [EMAIL PROTECTED]
Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?
Peter Tribble wrote: On 4/11/07, James Carlson [EMAIL PROTECTED] wrote: We could make the system less configurable by forcing SUNWxcu4 into SUNWCmreq or by just removing SUNWxcu4 and putting the binaries into SUNWcsu. Would that help? I like the second idea - remove the package entirely and make sure the files are always available under any conditions. (One could also ask why SUNWesu is a separate package.) I was under the impression that many people found our package breakdown already too coarse. Is this not the case? Perhaps Irek's concerns might be better met with a simpler method of adding elided Solaris packages during install of his product... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can not create /home/foo
Darren J Moffat wrote: Manoj Joseph wrote: Hi, On a box where Solaris has been freshly installed, one sees this behavior. -bash-3.00# useradd manoj -bash-3.00# tail -1 /etc/passwd manoj:x:100:1::/home/manoj:/bin/sh -bash-3.00# mkdir /home/manoj mkdir: Failed to make directory /home/manoj; Operation not applicable -bash-3.00# df -h /home Filesystem size used avail capacity Mounted on auto_home0K 0K 0K 0%/home While I realize why the mkdir failed, it is confusing for a new user who just did a useradd to create a new user account and needs to make the home directory. This morning, I saw an instance where a Linux user trying Solaris for the first time, found this very confusing. I am not offering solutions. But defaults that don't confuse a new user would be nice. Yep we know and there is a bug logged for it. Fancy fixing it so that useradd becomes aware of the automounter and just does the correct thing when useradd creates the home dir ? I'll sponsor the integration of the fix for you if you like. How about just fixing it so that the automounter finds any home directories in /etc/passwd and mounts those on demand? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can not create /home/foo
Doug Scott wrote: Bart Smaalders wrote: Darren J Moffat wrote: Manoj Joseph wrote: Hi, On a box where Solaris has been freshly installed, one sees this behavior. -bash-3.00# useradd manoj -bash-3.00# tail -1 /etc/passwd manoj:x:100:1::/home/manoj:/bin/sh -bash-3.00# mkdir /home/manoj mkdir: Failed to make directory /home/manoj; Operation not applicable -bash-3.00# df -h /home Filesystem size used avail capacity Mounted on auto_home0K 0K 0K 0%/home While I realize why the mkdir failed, it is confusing for a new user who just did a useradd to create a new user account and needs to make the home directory. This morning, I saw an instance where a Linux user trying Solaris for the first time, found this very confusing. I am not offering solutions. But defaults that don't confuse a new user would be nice. Yep we know and there is a bug logged for it. Fancy fixing it so that useradd becomes aware of the automounter and just does the correct thing when useradd creates the home dir ? I'll sponsor the integration of the fix for you if you like. How about just fixing it so that the automounter finds any home directories in /etc/passwd and mounts those on demand? I like it but shouldn't that be anything in getpwent(3C) rather than /etc/passwd? Sorry, I was not speaking clearly... We really want our home directories today to always be /home/user in /etc/passwd; that way things Just Work (TM) when we move from host to host. This does mean that we need another map to convert from /home/barts to wherever my home directory actually is... OR we need to change the semantics of /etc/passwd's home directory entry to point to the user's actual home directory and use that to drive the automounter to always force home directories to be mounted under /home/ via either NFS or a local loop-back mount. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can not create /home/foo
Manoj Joseph wrote: Bart Smaalders wrote: We really want our home directories today to always be /home/user in /etc/passwd; that way things Just Work (TM) when we move from host to host. I agree that it makes a lot of sense to be consistent. But hey, the installer, by default creates the filesystem '/export/home' and the name seems to suggest that that is the place to house home directories. Is that not the intent of that filesystem? Am I just confused? ;) -Manoj Solaris encourages users to have a single home directory across multiple machines; I can log into any machine at Sun and my home directory is always the same. In order to do this, we need to use part of the namespace in the filesystem in a location transparent fashion; the /home automounter map does this. If I log into my desktop cyber (which contains my home directory and exports it via nfs), cyber's automounter loopback mounts /export/home/cyber/barts onto /home/barts; if I log into jurassic the automounter there mounts cyber:/export/home/cyber/barts onto /home/barts and my files are where they belong. Thus my nis passwd entry's home directory entry of /home/barts always works - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Fresh Install Problems
I have seen a problem where a newer NVidia graphics card would hard-hang with the nv driver (used during install on older builds). This was with an 7900GT; the exact same problem was also seen with Ubuntu. Works fine w/ the Nvidia driver... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?
Shawn Walker wrote: On 06/04/07, I. Szczesniak [EMAIL PROTECTED] wrote: On 4/3/07, Steven Xie [EMAIL PROTECTED] wrote: Is this mean We should use Solaris original utilities under /usr/bin instead of posix ones under /usr/xpg/bin. It's really surprising. Well, we can live with it. We can barely live with it. Solaris is a very delicate platform when you try to rely on standards in your products. Many details which are standard on other operating systems are optional (especially POSIX and multibyte locale support) which makes it difficult to maintain a Solaris port. What other platforms are you speaking of? Linux isn't POSIX compliant, and most of the BSDs aren't. So which ones? And in addition, which ones don't support minimization to the point where multibyte locales are always present? -= Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [laptop-discuss] PROJECT PROPOSAL - Tadpole platform support
Garrett D'Amore wrote: I would like to propose the creation of a project to incorporate various platform specific support for Tadpole platforms into OpenSolaris. This would include core platform modules (for which I've already gotten an approved PSARC case), as well as power management, synaptics and PS/2 customizations, wlan support, and other features such as ebuttons and other features unique to the platform. I now have a recent code drop in my hands, which was graciously supplied to me courtesy of Tadpole (some of which I actually wrote while I was still employed at Tadpole), consisting of various kernel bits needed by these platforms, with a written understanding that I'm permitted to use this code for inclusion in OpenSolaris under the CDDL. (And Tadpole has signed an SCA.) Note also that one of these platforms, the SPARCLE, was also resold for a time by Sun as the Ultra 3. (The 15 models. The 17 models were from a Tadpole competitor.) Also, a lot of these improvements may benefit other platforms. For example, the synaptics trackpad support is likely to be useful on PC laptops, and the wlan support I have should make it possible to greatly improve the robustness and utility of the pcwl and pcan drivers. Having an umbrella project will help folks who are most interested in these platforms participate in a more focussed way. -- Garrett D'Amore ___ laptop-discuss mailing list [EMAIL PROTECTED] I'll second this; this seems like a fine idea. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling [was Re: Re: joining Sun]
UNIX admin wrote: Patches are not allowed to deliver upgrades or otherwise upgrade software on Solaris. Patches are explicitly not allowed to deliver new functionality. Upgrades do that. Patches are supposed to amend existing packages in a hopefully coherent fashion. Whether that amendment implements a new feature, fixes a bug or whatever is a function of the intent of the patch developer, not any intrinsic attribute of the patch or rule at Sun. Unfortunately, we don't rev package version numbers when we patch them; our packaging system is unaware of patches. We need to make the distinction between patching and upgrading go away; package versioning needs to be implemented. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Heads-up: ZFS Boot support for the x86 platform bld 62
John Brewer wrote: Is this URL availble http://fs.central/projects/zfsboot/how_to_netinstall_zfsboot out side on OpenSolaris site? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Take a look at: http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?
I. Szczesniak wrote: /usr/bin/tr is one of the big problems in Solaris - the behaviour is nonstandard and Sun declared long ago that fixes to support multibyte locales are off limits because they would break backwards compatibility. So use the one in /usr/xpg4/bin. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Is the cplus_demangle call mt-safe or async-signal-safe
Steve Clamage wrote: The cplus_demangle call is mt-safe, guarded by a mutex at the outer level. There is no external state, so I don't see how asynchronous signals could cause a problem. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Since the code uses a mutex, it cannot be async signal safe. A program that calls cplus_demangle in both normal and signal context can deadlock if a thread calling cplus_demangle receives a signal (either sync or async) and then attempts to call cplus_demangle from the signal handler; the mutex is already held by the locking thread. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mq_open fails with errno EEXIST(17)
Kushal Pal Singh wrote: Hi All, I dont know if this is the right place to post this query. I am having problem with mq_open. I have code like below: const int MQ_OPEN_FLAGS = O_RDWR; mQueueId = ::mq_open (pName,MQ_OPEN_FLAGS); In this case, mq_open is returning errno 17. I cant understnd the reason of this error as we are tryng to open an exisiting mq. In what situation errno 17 can be returned if called this way(to open existing MQ)? I know that file already exists thats why I called the mq_open with O_RDWR option. In what conditions errno 17 can be returned by mq_open. Thanks in advance This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org This might be better discussed on osol-code, but: 1) what version of opensolaris are you running? 2) have you written a simple test case? 3) what does truss of the test case report? 4) have you followed the code: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/rt/mqueue.c#352 - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: opensolaris 10 express community support Sata drive?
UNIX admin wrote: As subject content, I would like to know opensolaris 10 express community support Sata drive? I just want to make sure whether it support SATA or not? BEcause my PC only have 2 SATA drives. Tnx in advanced. There is no opensolaris 10 express community distro. Solaris 10 supports SATA in PATA emulation mode (and it's pretty fast, too). OpenSolaris and Nevada derived from it (future Solaris 11) supported SATA in PATA mode up until Nevada build 56 (snv_56 / b56). From snv_56 and on, SATA should be natively supported with the AHCI framework, according to this document: http://www.opensolaris.org/os/community/on/flag-days/pages/2006122401/ You can check which changes have been introduced into Nevada builds by going looking at flag day notices here: http://www.opensolaris.org/os/community/on/flag-days/ This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Whether or not your SATA drives work depends on the chipset, and whether or not that chipset also works in compatibility mode. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] smc hangs nevada 59
Patrick P Korsnick wrote: i've launched smc under cde and gnome on a fresh nevada 59 install and it hard locks the machine all 3 times i tried it. has anyone else experienced this? i'm gonna check bugs.opensolaris.org and file a report if i don't see one already. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Are these 32 bit x86? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RAID-Z: Just how big a performance hit does 32-bit give me?
Austin wrote: I'm currently getting !41 MB/s from /dev/zero writing to the filesystem, and ~50 MB/s from the filesystem to /dev/null. It's an array of 4 IDE 7200RPM drives running at ATA100, so theoretically, I should be able to get up to 100 MB/sec per drive, correct? Your disk performance is limited by rotational speed, not interconnect factors. The best you're going to see is on the order of 50MB/sec per drive. As James Dickens noted, you may be limited by the manner in which your drives are connected as well. Try dd'ing from each drive to /dev/null at the same time; this will quickly tell you if your configuration has issues here. I'm also wondering if the speed should be able to go over the maximum drive speed since I technically am writing to more then one drive. I'll probably be benchmarking it later on my desktop by importing and exporting (3800X2, 1 GB RAM), but more then 64 bit will be making a difference there. I would expect 4 drives that are capable of sustained 50 MB/sec at the same time to yield ~120MB/sec in raidz (3+1) and 160MB/sec in straight stripping mode, based on previous experiences and assuming adequate CPU. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RAID-Z: Just how big a performance hit does 32-bit give me?
Austin wrote: I guess I'll just have to do a bit of experimentation. Logically though if the 7200RPM drives have a typical output of 50 MB/sec, an ATA100 controller should be able to accomidate writing to both drives on the same channel at full speed though I would think. I should be able to throw a spare RAID card into my desktop when I test that out. Anyone have any experience with exporting your pool, rearranging what channels/adapters the drives are hooked up to, and importing it? Will it be that easy, or will I have to do a little bit more work to test things out? I've heard many horror stories about traditional RAID-5 systems being destroyed when reconnected wrong. ZFS takes care of this for you. In fact, it will happily cope with a drive appearing first on USB, then on FireWire and then via IDE or SATA. Just export the pool, and connect the drives to the new system. Import the pool by name on the new system and ZFS will find the drives and assemble your data for you. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
Laszlo (Laca) Peter wrote: Hi all, So the /usr/gnu proposal[1] was approved by PSARC. And there was much rejoicing! Obviously, the reason for defining /usr/gnu wasn't theoretical -- it allows moving GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us integrating more GNU packages into Solaris. We have already seen the first few putbacks (m4, bison). Specifically, it proposed the creation of /usr/gnu to accept those portions of FSF/UNESCO software that have conflicting names with already existing binaries. Software that doesn't conflict is targeted at /usr/bin. Note that there is little OSS software out there that conflicts w/ Solaris names that is not FSF/UNESCO. The JDS team (well, Dermot ;) is working on adding more packages (mostly the tools required for building JDS). Obviously, it's easier for us to deliver these through the JDS consolidation. However, they really don't belong there. Neither do some of the packages we already deliver into Solaris, like Python, libpng, libogg, etc. Well, consolidations are useful for software that has the same build procedures. In other words, unless there's a workload issue, I don't see anything wrong w/ the JDS team delivering Python, libpng, libogg, etc. I think the GNU Solaris community would be a perfect place for these, if it wasn't a community but a project (or a consolidation?). I propose that we launch a project that aims for creating a repository of spec files that follow the /usr/gnu rules. Sun could pick the packages that we want to integrate into Solaris and support, other packages could be available from opensolaris.org with community support only. I agree that a pkg-build based open source build consolidation is a great idea. I see no reason to limit it to stuff from GNU, though. How does this relate to: SFW: If proven successful, it would gradually phase out SFW. The idea is that this repository would be more inclusive (i.e. not only supported Solaris packages) and easier to contribute to than SFW. We'd have to make sure things were tagged correctly so we didn't deliver mplayer to Solaris Nevada by mistake ;-). CCD: Again, if proven successful, supersedes it. One big difference is that the CCD installs to /opt, while this repository would install to /usr. /usr belongs to the OpenSolaris name space right now. How would this work wrt ARC, etc? JDS: Co-exist. Non-desktop related tools and libs could be moved to this new repository. SFE: We have 200+ spec files written by various Sun and non-Sun opensolaris community members here: http://pkgbuild.svn.sf.net/viewvc/pkgbuild/spec-files-extra/trunk/ Those that satisfy the /usr/gnu criterion of being listed in the FSF/UNESCO free software directory can be moved into the new repository (after some clean-up and testing). We don't need to limit ourselves to FSF/UNESCO software Blastwave: This project would not support older releases of Solaris, not even S10. It would install to /usr and would not duplicate anything that is already in Solaris (especially since some of those parts of Solaris would be build from this repo). Thanks, Laca [1] http://mail.opensolaris.org/pipermail/opensolaris-arc/2007-January/000884.html So a qualified +1 :-). - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] RAID-Z: Just how big a performance hit does 32-bit give me?
Austin wrote: I installed Solaris on a computer with a RAID-Z array. Athlon XP 2500+, 512MB of RAM (which I'm going to double), 4 fast (by IDE standards) hard drives for the array. The speed was not anywhere near as fast in comparison to the Intel Marix Raid-5 on a friends WinXP system. Would upgrading to a 64-bit system of comparible speed really make that much of a difference? People have said so, but I haven't seen very many benchmarks to really convince me that this is that true. You didn't say how fast it goes... are those 4 separate IDE channels, or are you using both master and slave on two? If so, you're not going to be happy with the performance My 2.6 GHz dual core amd64 processor with 4 SATA drives in raid-Z config will sustain 120 MB/sec reading running build 55. Run 4 dd commands from the raw disk devices to /dev/null at the same time. This will let you know how fast the hardware will go. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Installing packages on the wrong arch (i386 v
UNIX admin wrote: On a personal workstation, you would expect pkgadd stall things in (say) /usr/bin where you can use them directly in your PATH. This will work for Sun and Sun packages, but will actually break for any third party packages, for example when trying to install them in a sparse zone. Besides, the System V spec mandates that no 3rd party should ever write to the /usr, the UNIX system resources directory. That directory is for the vendor and vendor alone to use, and must be off limits to everyone else, PATH convenience or no. PATH issues can be solved in other ways, whereas using /usr is just about one of the biggest faux-pas a 3rd party can make in a UNIX environment. One of the things I'd like to suggest is that we consider means for applications to appear in the default path more easily than requiring users to edit their .*rc files. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Installing packages on the wrong arch (i386 v SPARC)
Andrew Pattison wrote: I stupidly spent ages this evening wondering why my newly downloaded Firefox 2.0.0.1 wouldn't work, when all along I had dumped the i386 version on my Ultra 10 - doh! pkgadd happily added it to the system without any complaints - is this a general feature of the way Solaris packages work, or is the package missing something that marks it as being for one arch or the other, or arch neutral? Since one architecture can serve as an nfs server for another architecture, the packaging commands don't really question installing different architecture packages - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Fw: An opensource Sparc system...
Octave Orgeron wrote: Hi, purple/blue led's, lit sun logo, etc. It should be extremely quiet and The lit Sun logo is one of the coolest things I like about the SB1000. :-) It's the feature I love the most about my SB2k:) That would be the glogo. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: GPLv3?
Shawn Walker wrote: I think we know that. The SUN engineers are great people to work with. The whole closed bins issue though is a real dog. Yes, it's a PITA. However, anyone wishing to code replacements for such bins is _welcome_ to start a project to do this. This would be a great contribution to the community. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Samba license
Alex N wrote: Thanks for your response. So I guess that means there is no linking into the Samba code, as that would GPL all of OpenSolaris in my understanding? We build Samba on top of OpenSolaris and ship the resulting binaries. This also means that someone can develop proprietary non-open-source extensions of OpenSolaris that link with OpenSolaris code, as long as any mods of OpenSolaris files are open-sourced, but this would not be possible with the Samba code. yes, if by OpenSolaris code you mean that code that is licensed under CDDL. So these license distinctions are by source file I guess? Yes. There is code under many different licenses in OpenSolaris, including CDDL (duh), GPL, LGPL, Apache, BSD, Mozilla, ... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Porting Virtualbox to Opensolaris X86
UNIX admin wrote:
QEMU - on the other hand - is happy with gcc and
binutils alone, which
are widely available for almost any platform.
Except that GCC generates slow, crappy code. It's a big slap in GCC team's face that Sun
comes to i86pc as a latecomer with their compiler and trods them into the ground on their
own home turf.
How many years has GCC been evolving on the i86pc platform ag
This sort of polarizing remark isn't exactly useful. Gcc often
generates good code, sometimes better that the Studio compilers,
sometimes worse. On SPARC its track record is more mixed, but
that's really more of a code generation issue. There are many
very useful features in gcc; the support for inline assembler is
much better in gcc than in Studio, for example. On the other hand,
most floating point code (esp. hpc) yields significantly better
results with Studio.
There are no bug free compilers.
{Open}Solaris will compile with either one, and I for one will
argue to keep it that way.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Porting Virtualbox to Opensolaris X86
UNIX admin wrote: Perhaps engineering resources that went into making OpenSolaris GCC-friendly would have been better spent porting SS10 to other platforms? Were I the manager that had the power to decide, I would have certainly pushed in that direction, not the other way around. Both the original SPARC 64 bit port and the amd64 bit port were started with gcc. Solaris 10's x64 binaries are all compiled with the bundled gcc, as the Studio compilers weren't product quality soon enough during development. Being able to compile with gcc means that someone can much more readily port to another architectures, such as PPC or strongarm or ... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to find the number of cores on T1 processor
Nikolay Piskun wrote: I think this is more general for all processors, but I am mostly interested in T1 which is 8 core 32 virtual processors. The question is, is there any function call, that returns the number of cores instead of the number of virtual processors. Thanks, Why do you care? How will your code cope with more sophisticated processors a year from now? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: PRESTO - Automatic Printing Configuration
Norm Jacobs wrote: Purpose To improve Solaris approachability, specifically the print service, by automatically (or as automatically as possible) discovering and configuring access to directly attached, network attached, and remotely served printers. +1 If we can automatically discover broadcasting MAC and Windows network hosted printers and make them useable, and automatically/easily setup print queues and advertise them to Macs and Windows clients, it would truly be a huge step forward. - Bart Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Migrating User From Solaris 2.6 to 9
Andrew Pattison wrote: Sorry - I worded that badly. We're actually moving over to a completely new machine. Also, our existing system doesn't use shadow passwords - the passwords are stored directly in /etc/passwd. Can I simply copy the relevant lines from /etc/passwd to the new machine then? Thanks See the pwconv(1M) command; it does exactly what you want, I think. -= Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] swap space allocation
Gary wrote: Hello! Is there a rule of thumb for allocating swap space on a larger machine? For example, a V1280, 12 CPU's and 48Gb of memory. Thanks. This is a hard question; it depends entirely on your workload. If you don't give it much swap, any files you put in /tmp are effectively locked in memory. Same with each processes heap, stack, etc. So if your entire workload doesn't really need the 48G, running w/ minimal swap is fine. On the other hand, if you have processes creating multi-GB files in /tmp, or long running C++ parallel compiles w/ 100MB working set per CC instance, you're going to be happier w/ swap. Desktops often have large working sets with some apps that don't run for days - in this case, configuring swap really helps cut down on memory demands w/o affecting performance very much. Personally, I see allocating 20G of swap space in this situation as akin to a safety valve - you may never need it, but should things get tricky, you'll be glad you have it. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: x86 vs SPARC
Gino Ruopolo wrote: Also other sysadmin I know found the same when switched from Sparc to Opteron... Then you know the wrong sysadmins. :| Simple test: Compile some files in parallel (dmake -j X) on a 2 cpu box: (1) dmake -j 2 real 1:18.18 user 1:37.05 sys18.57 Load average: 1.32 dmake -j 8 real 1:12.24 user 1:37.65 sys18.42 Load average: 4.32 dmake -j 64 real 1:14.06 user 1:37.90 sys18.49 Load average: 11.86 me system time . only a slight increase in user time from -j 8 to -j 64 I'm not talking about 32-64 copy of the same process. 100 process is nothing! I was referring about having 10.000 - 40.000 process runnning for a total of 60-90 GB RAM My ---initial testing--- between a 4x880 Opteron and SF4800 12x USIII 1200 Mhz are showing lower load on the SF4800 when more than 10.000 process running. Anyway doing benchmark is not easy :) Load average isn't interesting. What is interesting is throughput... Now, I can well believe that 12 CPUs w/ 8M caches handle 10K processes more gracefully than 4 CPUS w/ 1M caches... What were you expecting to happen? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SIlly Question about exceptions
Eric Enright wrote: On 10/26/06, Robert Lunnon [EMAIL PROTECTED] wrote: Can anyone give me an explanation of what exactly would cause a signal for Segmentation Violation - Page - Fault to be returned. The Memory region accessed was previously accessed successfully then suddenly causes a page fault. Is there a way to look at the page attributes of a memory region in mdb or gdb ? If it was accessed successfully and then not, there was probably a free(3C) somewhere in between.. pmap(1) will print attributes for you. [EMAIL PROTECTED]:~ (1) pmap $$ 6298: /usr/bin/tcsh 08038000 64K rw---[ stack ] 0805 288K r-x-- /usr/bin/tcsh 080A7000 28K rwx-- /usr/bin/tcsh 080AE000 476K rwx--[ heap ] D0D7 20K r-x-- /usr/lib/locale/en_CA.ISO8859-1/en_CA.ISO8859-1.so.3 [...] (can also operate on a core) Note that a free using the normal libc malloc will not cause the page to be unmapped, which is required to get a segv. If you mmap a file MAP_SHARED and someone ftruncates the file, this can happen. It can also happen if your process simply unmaps the space itself. Pmap should indeed show the missing mapping. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: kstat information
Louwtjie Burger wrote: Hi Yep, I've completed my program to the point that I can sample cpu, io, memory and some other odd bits from kstat... using perl of course. I'm having a problem getting some usefull swap information however... from c there seems to be no problem ... just the kstat version isn't that usefull. So, I'm forced to use swap -s to sample the info into perl ... but it's not a nice solution. I'm using Solaris Performance and Tools, together with a healthy dose of the sourcecode browser ;) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org You can get useful data from the kstats. Given two times T1 and T2 (in seconds): (data[T2] - data[T1])/(T2 - T1) will yield the average values of data over the interval T1 - T2. Note that the summation interval is 1 second (internal impl. detail). - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kstat information
I set reply-to to opensolaris-code Louwtjie Burger wrote: bash-3.00$ kstat -m unix -n vminfo module: unixinstance: 0 name: vminfo class:vm crtime 47.129589548 freemem 232290532919 snaptime2847958.77893493 swap_alloc 45084054035 swap_avail 952763588224 swap_free 957527836045 swap_resv 49848301856 According to http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/sys/sysinfo.h the numbers are 'pages'. If I use pagesize and the 'pages' to calculate, I cannot get close to swap -s output. See swapctl(2) for a simpler interface. Note that the kstats increase forever they're added to once a second. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory distribution?
Nergal Dimitri wrote: Is there a way to explicitly limit the amount of memory a thread may use? I know that I can set this for a specific process, but can it be set for a specific thread that this process forks? Thanks, Nergal This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org No. Memory usage is a property of the address space, not a thread. Since all threads share the same address space, the same limits as to address space growth, etc, apply equally to all threads. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: Packet Event Framework (PEF)
Yu Xiangning wrote: Hello OpenSolaris folks, I would like to open an OpenSolaris project - Packet Event Framework (PEF), on behalf of the PEF project team. The Packet Event Framework project is a follow-on to FireEngine, which will provide a framework for fine-grain modularity of the network stack based on the execution of a series of event functions as specified by the IP classifier. PEF will provide the following benefits: - Better observability as the framework will support dynamic changes to an event vector. - Improved performance due to: - Smaller code footprint by executing the code needed based on packet classification only. - Iterative execution of events which leads to smaller stack depth. - Fewer parses of the packet. Packet parsing is done once at classification time. - Support for multiple vertical perimeters(squeue_t), so a packet can traverse from one squeue_t to the next. Currently FireEngine supports a single IP squeue_t requiring packet processing to use both STREAMS based queuing and FireEngine IP squeue_t queuing. As a result, a packet can be processed totally within PEF and does not require any STREAMS processing. - CMT(Chip Multi-Threading) based processors will additionally benefit from the multiple squeue_t support through pipe-lined processing of a connection. Multiple cores and/or threads of a core can process different layers of the stack. Also, packet fanout of packets such that multiple packets can be simultaneously processed. Thanks in advance for your support! - yxn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org +1 Sounds like this will improve performance significantly, esp. as networks increase in performance faster than single cpu cores - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: integrate GCCfss into SFW
Alexey Starovoytov wrote: Hi, In some sense this project is a supplement project to support GCCfss and gcc 4 in ON project, but can be considered separately. GCCfss (GCC for SPARC Systems) is a big step forward on sparc comparing to /usr/sfw/bin/gcc. Higher performance, higher reliability, internally supported. GCCfss 4.0.2 was released in March. GCCfss 4.0.3 is about to be released. The first idea was to propose plain gcc 4 for x86 side, but gcc needs few extra features to build ON, so it can't be plain gcc4. Yet another gcc branch with Solaris required features may be too costly. GCCfss contains all these extras already. For sparc and for x86 it can be made to be built from the same source tree. It will use Sun Studio backend on sparc and plain gcc backend on x86. GCCfss is sort of gcc plugin that allows gcc front-end to use Sun Studio backend. If plugin is off, vanilla RTL backend is called. Anyway it doesn't have to be decided right now. If ON community wants plain gcc 4 for x86 integrated in SFW, we can try to make it happen. Alexey. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org It seems to make sense to ship the compiler we use to build the OS with the OS. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Removing *all* traces of GNOME from one's home dir?
Rich Teer wrote: Hi all, How do remove all traces of GNOME from my home directory? I'm trying to play with b42a's GNOME 2.14.1, but from my earlier (read: months ago) messing about, I seem to have messed up the task bar at the bottom, such that iconised apps don't go there anymore. I've deleted the following directories from my home directory when logged in via CDE: .gnome2, .gnome2_private, .nautilus, and .metacity But when I log out and start a GNOME session, nothing seems to have changed. What am I doing wrong? TIA, While not running gnome, execute /usr/bin/gnome-cleanup. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Cdrecord 2.01.01a11 in the latest snv ?
Philip Brown wrote: On Thu, Jul 13, 2006 at 05:19:08PM -0400, James Carlson wrote: The original reason for /usr/sfw was to prevent users from wandering into External (extremely volatile; not necessarily compatible from patch to patch) software. But with GNOME integrating into /usr/bin as External and with the realization that the pain of torquing every $PATH was much higher than the value (if any) gained from the segregation, we've decided to drop the idea. (There are other reasons behind it, but the lack of a firm grounding for differentiation by stability was the key issue.) Pffft. How about avoiding the Microsoft Explorer/Media Player factor? In other words, having Sun recognize (in comparison to what microsoft did) that yes, their customers may want to run something OTHER than the sun-shipped browser/media player/GNOME version/ And you can... but making it harder to run the stuff Sun ships to make it easier for experts to run other code seems like exactly the wrong set of tradeoffs. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ZFS Boot and Install Opensolaris Project Proposal
Tabriz Leman wrote: The ZFS boot and Install project is responsible for providing install, boot, and root support for ZFS filesystems on Solaris. This project is still in the development phase and therefore unavailable to the OpenSolaris community. Without community exposure, we believe that we will be missing out on a lot of great feedback and possible code contributions. To take advantage of all that the OpenSolaris community has to offer, the ZFS boot team would like to propose the creation of an OpenSolaris project to serve as a forum for topics related to ZFS Boot and Install. By doing so, we hope that the community becomes involved in using our project and that we can solve/address any issues that the community requests before our release. If we are successful in doing so, we believe that we will have a better product upon Solaris integration. The ZFS Boot Team Lori Alt, Noel Dellofano, Tabriz Leman, and Lin Ling ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org +1... as a happy ZFS root user. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why is newfs and ufsdump so much slower in single user mode than in run level 3?
Steven Sim wrote: Hello; I frequently conduct the following operation; #ufsdump 0f - unmounted ufs raw device | (cd /mnt; ufsrestore xf -) I have noticed that the above takes place so much slower in single user mode than in multi user mode. A newfs operation on a local block device is also much slower in single user mode than in run level 3. I'm sure there is a reason for this but it eludes me. Also, would the mounting /mnt with the ufs forcedirectio option make the ufsrestore faster? e.g. #mount -F ufs -o forcedirectio /dev/dsk/c1t1d0s5 /mnt Warmest Regards Steven Sim That's a weird one. Is the /tmp filesystem mounted in single user mode? Do these utilities rely on /tmp files? You might add which version of Solaris and which hardware to help us guess more accurately :-). - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Lightweight ZFS NAS requirements?
Philip Brown wrote: you can also get the in-memory footprint down to about 64megs of RAM. this should be way under your requirements. It should be trivial to get a cheap small machine that has a 1ghz cpu with 128megs RAM, and that should be more than plenty for your needs. Given the cost of RAM, I don't think attempting to run ZFS in minimal memory makes sense. Stick 1 GB of RAM in the machine and be done w/ it. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Using lofs to overlay single files (like /lib/libc.so.1) ...
Roland Mainz wrote: Hi! Is there a way to overlay single files using lofs like /lib/libc.so.1 is a lofs-mount to a hardware-optimizsed version version ? I tried the same using mount but it refuses to operate on single files... ;-( How does the boot process get this working ? Bye, Roland Take a look at /lib/svc/method/fs-root; that's what does the mounting for libc. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: GCC Issues, was (Re: [osol-discuss] Re: Adobe Acrobat for Solaris x86)
David J. Orman wrote: Unfortunately, I absolutely have to agree here. With a dualcore cpu, multiple gigs of ram, and a 7900GT (which Nvidia assured me was supported with their binary driver), Solaris was *unusable* for me as a desktop due to this lag being described. It's almost like a stuttering. I saw it on network activity and hd activity *i think*. It was so terrible, I didn't even bother trying to diagnose it. I'm willing to give it another shot if somebody wants to help me figure out what the issue is. It's occured on lots of different hardware for me though, everything from old athlon xp systems to this current beast. All with Nvidia video cards, all using the binary nvidia driver. Oh, and intel 1000g ethernet cards. It's the *only* thing keeping me from deploying Solaris on my desktop as my primary development/administration platform. Help me! Weird. You see this on all sorts of hardware including dual core machines. What kind of hardware are you seeing this on now? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pthread_cancel() does NOT work with several threads
Luo Kai wrote:
See the following code:
test.c
#include sys/types.h
#include unistd.h
#include pthread.h
#include stdio.h
#include sys/resource.h
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void *func(void *a)
{
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
pthread_mutex_lock(mutex);
pthread_cond_wait(cond, mutex);
pthread_mutex_unlock(mutex);
return NULL;
}
int main()
{
int ii;
pthread_t tid[3];
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
for(ii = 0;ii 3;ii++)
{
pthread_create(tid[ii], NULL, func, NULL);
printf(tid = %d\n, tid[ii]);
}
sleep(2);
for(ii = 0;ii 3;ii++)
{
printf(cancel = %d\n, pthread_cancel(tid[ii]));
}
for(ii = 0;ii 3;ii++)
{
printf(join = %d\n, pthread_join(tid[ii], NULL));
}
}
---test.c
$CC -o test test.c -lpthread
$./test
tid = 2
tid = 3
tid = 4
cancel = 0
cancel = 0
cancel = 0
join = 0
main thread is blocked by pthread_join() for the thread with thread id 3.
I am wondering why pthread_cancel() can successfully cancel the thread with
thread id 2, but it can not cancel the threads with thread id 3 and 4. Threads
2, 3, 4 all were being blocked on pthread_cond_wait() before being cancelled,
and pthread_cond_wait() is a cancellation point.
I tested the code on both Sparc/solaris10 and linux and both platforms have the
same issue.
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
From the pthread_cond_wait man page:
A condition wait (whether timed or not) is a cancellation
point. When the cancelability enable state of a thread is
set to PTHREAD_CANCEL_DEFERRED, a side effect of acting upon
a cancellation request while in a condition wait is that the
mutex is re-acquired before calling the first cancellation
cleanup handler.
A thread that has been unblocked because it has been can-
celed while blocked in a call to pthread_cond_wait() or
pthread_cond_timedwait() does not consume any condition sig-
nal that may be directed concurrently at the condition vari-
able if there are other threads blocked on the condition
variable.
My guess is (since the stack traces are the same) that this hold
true whatever the type of cancellation is... so a correct program
would have a cancellation handler to release the mutex. Note that
in real life this would be complicated by the fact that cancellation
could occur before the mutex was grabbed I strongly recommend
not using async cancellation; it's extremely difficult to use
correctly.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Sequencers/music editors on Opensolaris
[EMAIL PROTECTED] wrote: *) If I understand you you correctly and you like to see a tool that is able to do this with any unknown random feature. You would always hand code tests for some of the OS features. Well, in some way. But you could have a library with a lot of common features and symbols. People also do not test for all the things they use (which is wrong but also cumbersome; all you can really rely on, I think, is the ANSI C library function set. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org So what is needed is a tool that examines a working program and it's libraries, and produces a configure script. It would flag functions that have no configure support or that are known not to be portable. This would mean that properly written configure macros for various features would need to be generally available. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
