zone.max-shm-memory defines the maximum size of a
shared memory segment. So if it is set to 4Gig then
the maximum shared memory segment will be 4 Gig.
Sorry, but that is incorrect. zone.max-shm-memory limits the *total* amount of
shared memory that can be allocated by a zone, *not* the size
Mike Watkins wrote:
is going from 2009.11 to Nevada b116 (or now b117) possible?
I'm thinking reinstall...
Can someone confirm?
If you use the 'dev' repository for 2009.06, you should be able to
upgrade to build 116 shortly.
___
Yup. This is 6174625 ::memstat should not show ridiculous amounts of free memory
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
laptop, I'm fairly impressed with their product. What I object to
is the fact that the *project* Indiana seems to have unilaterally taken
possession of the name OpenSolaris, and even the homepage of
opensolaris.org as if there weren't any other OpenSolaris distributions.
Menno
--
Menno Lageman
Shawn Walker wrote:
On 01/11/2007, Menno Lageman [EMAIL PROTECTED] wrote:
John Plocher wrote:
Brian Gupta wrote:
In other words, Ian seems to have decided that democracy is a bad way
to run an open source project, and wants to install himself as
benevolent dictator.
OpenSource efforts
- Original Message -
From: Douglas Atique [EMAIL PROTECTED]
Date: Wednesday, March 14, 2007 7:01 pm
Subject: [osol-discuss] Re: Solaris Express b59
To: opensolaris-discuss@opensolaris.org
ok, so I have a little bit more information on this. I managed to
boot with kmdb loaded and set
Doug Scott wrote:
For you who don't know, Xfce is a lightweight desktop built using the gtk+
libraries.
Currently there is a very old verion of Xfce as part of the companion CD with
no owner.
I am proposing to move the development to a project within the Desktop
Community,
where it shares
Dennis Clarke wrote:
I personally have always wondered why the ps command display what root is
doing to ordinary users like as if it is any of their business but that
is another idea I just let rattle around in my head.
Dennis,
You can do this (in Solaris 10 and up) by taking away the
Dennis Clarke wrote:
Hi Dennis
0 [EMAIL PROTECTED] ~ # uname -a
SunOS topgun 5.11 snv_43 i86pc i386 i86pc
Made the entry into /etc/user_attr
mritundefaultpriv=basic,!proc_info
Before:
0 [EMAIL PROTECTED] ~# ps -ef | wc -l
84
After (logout then again login)
0 [EMAIL PROTECTED] ~# ps
Glynn Foster wrote:
Hey,
Planet OpenSolaris is now live and unleashed!
http://grommit.com/pos
You'll notice a couple of things from the outset. The current blogroll only
includes a small selection of people right now. We obviously hope to expand this
list in the future, but any additions
Hello opensolaris-discuss,
I had to re-install to snv_51 on my x64 workstation.
Installer didn't offer upgrade option - :(((
Did you have any zones configured perhaps? If zones are present you won't be
presented with the Upgrade option.
Menno
. But it is only there for compatibilty reasons
so you really should be using project.max-msg-ids...
HTH
Menno
--
Menno Lageman | [EMAIL PROTECTED]
Sun Microsystems | http://blogs.sun.com/menno
___
opensolaris-discuss mailing list
opensolaris
the
appropriate resource control to the project Oracle runs in.
An example of how to do that can be found at page 24 of this BluePrint
http://www.sun.com/blueprints/0505/819-2679.pdf.
Menno
--
Menno Lageman | [EMAIL PROTECTED]
Sun Microsystems | http://blogs.sun.com/menno
Michael Pogue wrote:
I have a suggestion: in another current thread, Build times for Open
Solaris, there's discussion about build parallelism on a Niagara
(T1000), and how we don't get much benefit in build time beyond 4 CPUs.
I just retracted that statement... It does improve with more
Holger Berger wrote:
I think one part of this jigsaw is the disk bottleneck. If you build
ON on a tmpfs volume you should have a far better CPU utilisation on
Niagara.
Nothing beats real data, so I ran a nightly on a tmpfs file system with
max jobs = 32. The build time decreases from 1:53
I happen to have access to a T2000 (1 GHz, 32 strands) for a couple of days, so
I ran a nightly of on20050327:
Nightly distributed build completed: Thu Apr 13 22:17:16 CEST 2006
Total build time
real2:26:51
This was with the default max concurrent jobs = 4. Increasing
technical efforts might generate separate projects.
Excellent idea, count me in.
Menno
--
Menno Lageman | [EMAIL PROTECTED]
Sun Microsystems | http://blogs.sun.com/menno
___
opensolaris-discuss mailing list
opensolaris-discuss
17 matches
Mail list logo
