Re: CVS commit: src/sys/arch/x86/x86
Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name: src Committed By:jmcneill Date:Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver?
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name: src Committed By: jmcneill Date: Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver? I am not sure. But have we thought about all the consequences and corner- cases? Unloading happens while modifying hardware state? Deferred calls in the drivers? And so on? To me it also seems that if I manually load a driver-module, I expect it to stay loaded until I unload it. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On 18 October 2011 10:07, Jukka Ruohonen jruoho...@iki.fi wrote: On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name: src Committed By: jmcneill Date: Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver? I am not sure. But have we thought about all the consequences and corner- cases? Unloading happens while modifying hardware state? Deferred calls in the drivers? And so on? To me it also seems that if I manually load a driver-module, I expect it to stay loaded until I unload it. Presumably whether to permit autounload should be an option that can be specified at manual module load time, then the default is less important.
Re: CVS commit: src
On Tue, Oct 18, 2011 at 09:50:25AM +, Thomas Klausner wrote: Module Name: src Committed By: wiz Date: Tue Oct 18 09:50:25 UTC 2011 Modified Files: src/distrib/sets/lists/man: mi src/share/man/man4: Makefile Added Files: src/share/man/man4: vmt.4 Log Message: Add vmt(4) from OpenBSD. This should probably be in man4.x86. - Jukka.
Re: CVS commit: src
On Tue, Oct 18, 2011 at 01:15:08PM +0300, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 09:50:25AM +, Thomas Klausner wrote: Module Name:src Committed By: wiz Date: Tue Oct 18 09:50:25 UTC 2011 Modified Files: src/distrib/sets/lists/man: mi src/share/man/man4: Makefile Added Files: src/share/man/man4: vmt.4 Log Message: Add vmt(4) from OpenBSD. This should probably be in man4.x86. I've moved the page. This arguably also applies to the bogus vmnet(4) man page. Thomas
Re: CVS commit: src/sys/arch/x86/x86
I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver? I am not sure. But have we thought about all the consequences and corner- cases? Unloading happens while modifying hardware state? Deferred calls in the drivers? And so on? To me it also seems that if I manually load a driver-module, I expect it to stay loaded until I unload it. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That sounds right to me. As noted, generally I am not sure what my opinion about autounloading really is. But it feels somewhat awkward and error-prone that drivers must protect themselves against the autounloading kthread. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That sounds right to me. As noted, generally I am not sure what my opinion about autounloading really is. But it feels somewhat awkward and error-prone that drivers must protect themselves against the autounloading kthread. How often is autounloading actually effectively used anyway? I mean, if the module is loaded automatically, it is because the system found that it was needed. So, yes.. there situation where eg USB or PCMCIA devices might have a transient need for a driver, but on the other hand, the overhead of a driver being in memory is not that great considering that you used it once, as the chance of re-use is significant (higher by far than all the other drivers that have never been needed) The real benefit of the modular system is that you don't need to load hundreds of modules on the off chance that they will be used. A cron entry could be used to flush unused modules if the sysop cares about that, why do we need a kthread running? iain
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 12:44:52PM +0100, Iain Hibbert wrote: The real benefit of the modular system is that you don't need to load hundreds of modules on the off chance that they will be used. A cron entry could be used to flush unused modules if the sysop cares about that, why do we need a kthread running? A good question worth asking. And as far as I remember, the autounloading cycle was as low as 10 seconds (!), whereas a proper scale would be measured in minutes or hours in my opinion (or even as daily(5)). - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, 18 Oct 2011, Jukka Ruohonen wrote:
On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote:
I would argue that any manually loaded module shouldn't be autounloaded.
What do you think about flagging modules as autoloaded and only
autounloading the autoloaded ones?
That sounds right to me.
I was under the impression that we would already only auto-unload
modules that were auto-loaded. The comment in module_thread() says
* Automatically unload modules. We try once to unload autoloaded
* modules after module_autotime seconds. ...
module_thread() skips modules with mod-mod_autotime of zero, and at the
end of module_do_load() we have
if (autoload) {
/*
* Arrange to try unloading the module after
* a short delay.
*/
mod-mod_autotime = time_second + module_autotime;
module_thread_kick();
}
So mod-mod_autotime is only set if the module was autoloaded.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: CVS commit: src/sys/arch/x86/x86
Well I loaded vmt manually and it was auto unloaded on me a few minutes later,
that's why I made this change in the first place.
On 2011-10-18, at 7:57 AM, Paul Goyette wrote:
On Tue, 18 Oct 2011, Jukka Ruohonen wrote:
On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote:
I would argue that any manually loaded module shouldn't be autounloaded.
What do you think about flagging modules as autoloaded and only
autounloading the autoloaded ones?
That sounds right to me.
I was under the impression that we would already only auto-unload modules
that were auto-loaded. The comment in module_thread() says
* Automatically unload modules. We try once to unload autoloaded
* modules after module_autotime seconds. ...
module_thread() skips modules with mod-mod_autotime of zero, and at the end
of module_do_load() we have
if (autoload) {
/*
* Arrange to try unloading the module after
* a short delay.
*/
mod-mod_autotime = time_second + module_autotime;
module_thread_kick();
}
So mod-mod_autotime is only set if the module was autoloaded.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 07:59:35AM -0400, Jared D. McNeill wrote: Well I loaded vmt manually and it was auto unloaded on me a few minutes later, that's why I made this change in the first place. On 2011-10-18, at 7:57 AM, Paul Goyette wrote: On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That sounds right to me. I was under the impression that we would already only auto-unload modules that were auto-loaded. The comment in module_thread() says * Automatically unload modules. We try once to unload autoloaded * modules after module_autotime seconds. ... True. But like Jared, I've also seen magic unloading of some of my driver modules. I guess there is a bug somewhere. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
No wonder, in the thread if uvmexp.free uvmexp.freemin it skips the mod_autotime == 0 check. On 2011-10-18, at 8:06 AM, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 07:59:35AM -0400, Jared D. McNeill wrote: Well I loaded vmt manually and it was auto unloaded on me a few minutes later, that's why I made this change in the first place. On 2011-10-18, at 7:57 AM, Paul Goyette wrote: On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That sounds right to me. I was under the impression that we would already only auto-unload modules that were auto-loaded. The comment in module_thread() says * Automatically unload modules. We try once to unload autoloaded * modules after module_autotime seconds. ... True. But like Jared, I've also seen magic unloading of some of my driver modules. I guess there is a bug somewhere. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
Fixed. On 2011-10-18, at 8:06 AM, Jukka Ruohonen wrote: True. But like Jared, I've also seen magic unloading of some of my driver modules. I guess there is a bug somewhere. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? If I manually load a dozen drivers at boot because I have a dozen different boards with different devices. I'd kinda like the system to automatically figure out what isn't needed and unload those drivers. Warner On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name: src Committed By: jmcneill Date: Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver? I am not sure. But have we thought about all the consequences and corner- cases? Unloading happens while modifying hardware state? Deferred calls in the drivers? And so on? To me it also seems that if I manually load a driver-module, I expect it to stay loaded until I unload it. - Jukka.
Re: CVS commit: src/share/man/man4/man4.x86
On Tue, Oct 18, 2011 at 02:25:06PM +, Thomas Klausner wrote: Module Name: src Committed By: wiz Date: Tue Oct 18 14:25:06 UTC 2011 Modified Files: src/share/man/man4/man4.x86: vmt.4 Log Message: Fix xref; comment out cpu(4) reference, does not exist. We could write one though... If nothing else, to list the things that attach to CPUs via autoconf(9). - Jukka.
Re: CVS commit: src/sys/fs/puffs
On Tue, Oct 18, 2011 at 03:39:10PM +, Emmanuel Dreyfus wrote: Module Name: src Committed By: manu Date: Tue Oct 18 15:39:09 UTC 2011 Modified Files: src/sys/fs/puffs: puffs_msgif.c puffs_node.c puffs_vfsops.c puffs_vnops.c Log Message: Make sure pagedaemon does not sleep for memory in puffs_vnop_sleep. Add KASSERT on any sleeping memory allocation to check it cannot happen again. +#ifdef DIAGNOSTIC + KASSERT(curlwp != uvm.pagedaemon_lwp); +#endif Why pollute code with redundant #ifdefs? - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Oct 18, 2011, at 9:28 AM, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 08:49:39AM -0600, Warner Losh wrote: On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? If I manually load a dozen drivers at boot because I have a dozen different boards with different devices. I'd kinda like the system to automatically figure out what isn't needed and unload those drivers. The general idea here probably is that you shouldn't actually load manually all those drivers, but the system should be able to autoload modules specific to your hardware. But we are not there yet. And AFAIR, neither is FreeBSD. That's true. It is a hard problem that people have been working around by manually loading things. :) Warner
Re: CVS commit: src/sys/fs/puffs
Jukka Ruohonen jruoho...@iki.fi wrote: +#ifdef DIAGNOSTIC + KASSERT(curlwp != uvm.pagedaemon_lwp); +#endif Why pollute code with redundant #ifdefs? Right, I missed the point that KASSERT contains #ifdef DIAGNOSTIC. I will fix that tomorrow morning. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: CVS commit: src/sys/arch/x86/x86
Am 18.10.11 12:39, schrieb Jared McNeill: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? I'd say that is a safe way. I am for it. On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name:src Committed By:jmcneill Date:Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver? I am not sure. But have we thought about all the consequences and corner- cases? Unloading happens while modifying hardware state? Deferred calls in the drivers? And so on? To me it also seems that if I manually load a driver-module, I expect it to stay loaded until I unload it. - Jukka. -- \~.The NetBSD Foundation \~' Marc Balmer, Developer / Marketing NetBSD \ mbal...@netbsd.org http://www.NetBSD.org/
Re: CVS commit: src/sys/arch/x86/x86
Am 18.10.11 13:44, schrieb Iain Hibbert: On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? When I manually load gpiosim, it will autoload gpio. Now when I manually modunload gpiosim, gpio will stay there. But in this case, I want gpio to be autounloaded eventually. That sounds right to me. As noted, generally I am not sure what my opinion about autounloading really is. But it feels somewhat awkward and error-prone that drivers must protect themselves against the autounloading kthread. How often is autounloading actually effectively used anyway? I mean, if the module is loaded automatically, it is because the system found that it was needed. So, yes.. there situation where eg USB or PCMCIA devices might have a transient need for a driver, but on the other hand, the overhead of a driver being in memory is not that great considering that you used it once, as the chance of re-use is significant (higher by far than all the other drivers that have never been needed) The real benefit of the modular system is that you don't need to load hundreds of modules on the off chance that they will be used. A cron entry could be used to flush unused modules if the sysop cares about that, why do we need a kthread running?
