On Wed, 23 Mar 2005 15:54:20 -0500, David Kreuter
<[EMAIL PROTECTED]> wrote:
> It's truly a great thing to do - but it is not as I recall a supported mode
> of production from IBM or the distributors.
> So sadly I can't use it at some of my clients.
> The more code and data the get shared the better.
Indeed. It does save a bundle. Having the kernel in NSS makes IPL of
Linux so quick ("I thought you were going to reboot...") that I am
thinking about IPL the developer virtual machines when the first IP
packet for ssh arrives.
My "Squeezing Penguins" presentation has some numbers on how much
memory you can save. http://www.vm.ibm.com/events/nl76.pdf
We modified s390-tools to allow for the NSS to be saved just like we
save CMS, but I never got my friends in Boeblingen to pick that up
(the way we deal with CMS is not intuitive to them and so they will
come up with their own process).
We also have the kernel modules on a shared R/O disk for all kernels
that we run in NSS. So all it takes for a kernel upgrade is to change
the NSS that the virtual machines IPL from (eg directory profile). No
serviceable kernel parts inside.
The support issue lies in the fact that the kernel variables in the EW
portion of the NSS are lost when you do a stand-alone dump. As we know
VMDUMP does that, and you can now even convert that to lcrash dump
that support teams want to have. Then you have the problem that vmdump
does not work for very large virtual machines (but I think that is
less significant because saving 200 pages on a 2G virtual machine is
less exciting).
And this is not for supporting possible problems in NSS usage. If they
can not proccess the dump that also impacts issues that are not
related to NSS at all.
I still do not understand why the distributions do not build a kernel
that allows sharing. That would help. You could still run it
non-shared and have the ability to do stand-alone dump. And you could
use the same kernel in NSS without having to recompile it and lose
support completely. The only drawback imho is that you lose almost 1
MB of address space (not memory because on z/VM those pages are never
allocated). Somehow I fail to get the message through to those who
make a difference.
> Should have a look at the supported XIP2 overlay files in segment method.
> Save a lot of storage too.
Yes. I have some numbers in that presentation, works great. The
restrictions are similar to what you have with sharing code on R/O
disk: it gets real hard to update the code and maintain consistency.
Still, you may be able to live with that for a set of servers and take
advantage of this way to save memory.
Rob
--
Rob van der Heij rvdheij @ gmail.com
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
