Mark Martin wrote: > > [Resent for Reply-all] > > On Sat, Oct 18, 2008 at 6:03 PM, Martin Bochnig <mar...@martux.org> > wrote: > > +1 > > Except that it would be nice if somebody would make the > Polaris port functional, before starting a new port. > Also, why MIPS, not ARM? Isn't MIPS dead a bit? > > Thanks for the vote and the feedback. > > I believe the PowerPC is either lacking consensus on a platform or > lacking other resources (or both). I agree that the PowerPC has some > attractive features, but lack of a valid, available platform and > resources I think is contributing to its dormancy. I believe that > interest continues for that platform, but once Sun Labs discontinued > development support, the project seems to have gone into hibernation. > > Someone mentioned interest in an ARM a short while ago, but in my > research, I could not find a solid, available platform that provided > enough physical resources -- namely 256MB to 512MB RAM,
Assuming you only use UFS and cut-down some system tuneables Solaris can run on a 64MB machine (my Ultra5 only has 128MB now after one of the DIMMs failed and it still works fine with CDE). The problems start if you want to run some of the memory-hogs, e.g. ZFS, JAVA or a X11 server - then you either need a swap device or much more memory. Beyond that I think we need a project which works on lowering the memory footprint of Solaris - for example as I already wrote in http://mail.opensolaris.org/pipermail/opensolaris-code/2007-March/004430.html -- snip -- > Another issue is the way how applications in Solaris allocate temporary > memory (this applies to the kernel but a "solution" is much more tricky > because the kernel's stack can't grow which limits it to 4k on i86 and > 8k on UltraSPARC (UltraSPARC may be in a better position since it could > map the stack with 64k pages (which runs into other problems since lots > of code doesn't expect a "custom" page size for kernel stacks... ;-(( > ))) - IMO in many places the usage of |malloc()| should be replaced with > |alloca()| or C99's variable length arrays assuming the size does not > exceed a given size (some sample code can be found in > http://mail.opensolaris.org/pipermail/perf-discuss/2007-February/001589.html). > This solution would have lots of advantages, for example: > - Multithreaded applications would not go through the heap each time, > e.g. avoid locking/syscall overhead in the worst case > - Better locality of data - the thread's stack is assumed to be closer > to the running CPU than a "random" page in the heap > - It is "easier" (the explanation of this is little bit beyond the scope > of this email, basically some UltraSPARC CPUs seems to have trouble > handling more than two different pagsizes at the same time except the > number of pages for a 3rd/4th size is very small) to map the stack with > largepages than the whole heap of an application > - Avoid taxing the heap with lots of small temporary allocations -- snip -- If we could fix the way how these allocations are done many issues with memory wasting and kernel allocator scalability (or better: Many temporary allocations will done in the per-thread memory "stack" and no longer go through the SLAB code) will simply go away. ---- Bye, Roland P.S.: Setting Reply-To: to on-disc...@opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
