James:
Thanks for the reply. You illustrate the routine sequences
which offer the functionalities which S10 kerenl addresses.
However, there is another aspect of the kernel capability is
to manage the resources such as processor, cores etc. for
kthread invocation and execution. In additon, for LWP and
user land thread resource usage, S10 container SRM and
realated model per zone management would consider hypervisor
can be do ?
Lei
James Carlson wrote:
Lei Liu writes:
On the performance overhead per 0 over head for applications,
could you please explore a bit from engineering perspective ?
In addition, I thought Solaris 10 kernel will leverage the optimization
can be done over hypervisor for Processor resource usage ?
The engineering perspective is fairly simple: a zone is no greater
overhead than (say) a UID or a chroot. Inside the kernel, zones are
just integers embedded in the relevant data structures. The system
still works as it always has in the past, but it has just one more
integer comparison to make in certain circumstances.
It's not at all the same as a virtualization layer, such as an LPAR or
hypervisor.
I know that "zero overhead" sounds like so much fluff, but it's really
quite true. For example, take a look at ipcl_classify_v4, here:
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/inet/ip/ipclassifier.c#1159
(Sorry about the line numbers rather than more stable references;
they'll likely be out of date the next time the source is updated, but
I don't have a better mechanism.)
Examine the IPPROTO_TCP case. The first loop (lines 1178-1184) scans
through a hash of fully-bound connections. This part is the same as
it's always been. Except for some recent variable name changes, the
code has been present for many users. There's no overhead from Zones
here.
If we don't find a (by definition unique) fully-bound connection, then
we fall into the loop at 1197-1203. Here, we're looking for "listen"
sockets. Note line 1201. That's it -- that one comparison is the
"Zones overhead." In the case where we find a matching listen socket,
we check that the zoneid (derived from the initial IRE_CACHE [address]
lookup) is the right one.
In most cases, the code just does what it's always done before,
because every object (connection, file descriptor, process) has some
unique object in the kernel, and that identification (pointer) is
still sufficient to know which thing we're operating on. In the cases
where we must look something up in a table or database -- the cases
that are naturally minimized for performance reasons (no matter how
fast the lookup can be made, avoiding it is better) -- we now have to
add zoneid to the list of things to match, along with ports, UIDs,
PIDs, or whatever else it was we were matching.
--
Lei Liu (Larry)
Member of Technical Staff
Horizontal Technology
Software MAX
Mailstop: UNWK 12-209
Address: 7777 Gateway Boulevard, Bldg 12 Newark, CA 94560
Phone: (510) 574-7187 (x37187)
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Fax: (510) 574-6074
Blog:http://ttoulliu2002.blogspot.com
Skype: ttoulliu2002
_______________________________________________
opensolaris-discuss mailing list
[email protected]
