On 6/27/06, Jeff Victor <[EMAIL PROTECTED]> wrote:
1) General comment: I agree that this will provide needed clarity to the 
unorganized RM features that we have scattered through Solaris during the last
decade. The automation of certain activities (e.g. starting rcapd in the GZ when
needed) will also be extremely beneficial.

Most definitely.

2) Terminology: Although your use of the phrase "hard partition" should be clear
to most people, through experience with other partitioning technologies, the use
of "soft partition" is less clear. To many people, a "soft" limit is one that 
be exceeded occasionally or in certain situations, or is merely an advisory 
It also conflicts with SVM "soft partitions."

I suggest the phrases "dedicated partition" (or "private partition") and "shared
partition" instead to clarify the intent.  Choosing "dedicated partition" might
then require re-naming "dedicated-cpu" to "guaranteed-cpu" or "private-cpu" and
re-naming "dedicated-memory" to "guaranteed-memory" or "private memory".

Or we could leave "hard partition" alone and simply change "soft partition" to
"shared partition."

I think that "soft partition" is more clear.  "Shared partition"
suggest to me that you are sharing a single hard or soft partition for
multiple workloads.

3) Lwps context: Why is the lwps alias defined in the context of dedicated-cpu?
Lwps seem to be unrelated to hard partitions.  Further, ncpus represents a 
of a finite resource. Lwps are not finite.  The two should be separate.

Something seemed odd with that to me too.  I didn't see it as terribly
harmful there, but it is an excellent point.  This is analagous to
maxuprc typically set in /etc/system.  What are the chances that each
zone in the future gets file descriptor limits or other similar limits
that should be in the same section as the lwp limit?

4) Aliases: The notion of aliases also creates redundant output which could be
confusing.  I like the simplification of aliases as described, but I wish I had 
good solution that wouldn't break existing tools that parse "zonecfg info" 
- if such tools exist.

Because key features are missing from zones, I have been writing
scripts that sometimes parse the output of "zonecfg info".  Changing
this format stands a good chance of breaking my scripts.  It sounds
like if I set pool and rctl resources, they would still be displayed
as rctl and not translated to the syntax associated with temporary
pools.  Is this correct?


Mike Gerdts
zones-discuss mailing list

Reply via email to