Thanks for your comments.  I have a few responses in-line.

Jeff Victor wrote:
1) General comment: I agree that this will provide needed clarity to the seemingly 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.

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 can be exceeded occasionally or in certain situations, or is merely an advisory limit. It also conflicts with SVM "soft partitions."

We started using "hard" and "soft" to describe the general idea amongst
ourselves when we first started talking about this but we were never
very satisfied with those terms either.  These two terms will not necessarily
be used in the final documentation and are not used in the resource names
themselves.  Naming always seems to be a difficult area.  The key technical
issue to focus on is the resource names and properties being proposed as
opposed to the overall words we are using to describe the general ideas.
I am guessing we were able to communicate the general idea using "hard" and
"soft" so I think we are ok there.  We will have to figure out the best way
to document this when the time comes.  It is hard to find good terms that
are not already used by other parts of the system.  The word "resource" is
a good example and is probably more confusing than "soft partition".

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 subset of a finite resource. Lwps are not finite. The two should be separate.

Being able to set max-lwps is a useful limit for both processor sets
and cpu-caps which is why it is available in both resources.  The global
zone still manages all processes, even when you are using a processor
set, so a fork bomb can still effect the responsiveness of the system
as a whole.  However, max-lwps is optional in both the dedicated-cpu and
capped-cpu resources.  I should have made that clearer.  I will
update the document to clarify that.

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 a good solution that wouldn't break existing tools that parse "zonecfg info" output - if such tools exist.

This is part of the proposal which we struggled with a lot.  In the
end, we decided that we needed to maintain compatibility so that
we did not break scripts that talked to the CLI directly.  This was the
compromise we came up with that allows us to do that.

5) Another RM setting: While we're integrating RM settings, I think we should consider adding project.max-address-space using the same semantics as {project,zone}.max-lwps. A zone-specific setting, zone.max-address-space, could be added along with a zonecfg alias, max-address-space. This would allow the GZ admin to cap the virtual memory space available to that zone. This would not take the place of swap sets, but would be valuable if this RM integration work might be complete before swap sets.

We are looking at additional rctls, they are just not part of this project.

Thanks again for your comments,
zones-discuss mailing list

Reply via email to