On Wed, 2 Jan 2008, Ed Maste wrote: > On Tue, Jan 01, 2008 at 10:27:28PM -0600, Mike Silbersack wrote: > >> It looks like we're going to go with an alternate implementation that >> resides in the loader instead. The effect will be the same, and it should >> be committed within a few days. > > I've attached a proof of concept patch that does this in forth in the > loader. I've been using something similar for a while; this patch isi > cleaned up somewhat and I've added the kenv strings from Mike's patch. > > I've only tried it out with qemu so far. I'd appreciate reports of any > testing with other emulators, and comments from loader/forth gurus. With this patch, is one forced to use a HZ of 100 when running under a VM unless one modifies the loader scripts? There are times when I experiment with alternative HZ settings in VMs, and as such it would be nice to have an intentional way to turn off auto-setting of HZ, and/oor specify what the VM HZ should be, using loader.conf. I.e.: vmadjusthz_enable="NO" and vmadjusthz_hz="50" Allowing me to either manually disable the override of kern.hz, or to specify what the replacement value should be. One other variation I'd sort of been thinking about was using the loader to set a kernel environmental variable indicating that we're in a VM, but then letting the kernel decide what to do about it, per my previous suggestion to silby. That way we could define a kernel option in GENERIC the same way we do HZ: options VMHZ="100" The loader would make the decision as to which would be used, but the logic to implement the HZ change would be in the kernel. And loader.conf's kern.hz would still be able to override it... I just want to make sure that we retain all the current flexibility to modify HZ at boot-time while having the default be more sensible. Robert N M Watson Computer Laboratory University of CambridgeReceived on Wed Jan 02 2008 - 17:31:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:24 UTC