Re: kernel module
2010/1/9 Luca lucar...@gmail.com: Hi all, I created a kernel module which can be passed some command line arguments (I tried that with insmod and it works). Now I would like, when I start the kernel with grub, to have this module loaded at boot time so I can pass, at boot time, a kernel boot option to it. I think this usually happens in a modules configuration file. Something like this? https://fedoraproject.org/wiki/KernelCommonProblems#How_to_set_module_options_for_boot_drivers; -c -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: kernel module options for cpufreq
On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state I don't think removal of powersave governor is good idea. Generally ondemand governor does great job but in some cases doesn't. For example when I play some films in mplayer ondemand sets frequency to max which is not needed, of course. Powersave governor is also good in case that you have bad fan in your laptop and you are going to compile some big source. Without powersave it is not possible (yes, it really happens :) ) Matthew Garrett and I are working on a latency profile for power management, and having all these modules potentially loaded is bad. Comments? I think we should preserve ondemand and powersave governors (and potentialy others as Dave Jones wrote in this thread). Please don't drop them in favour of your project which might be generally better but I believe there are cases where current governors are better. Adam -- Adam Tkac, Red Hat, Inc. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Mon, 2008-06-30 at 09:10 +0200, Adam Tkac wrote: On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state I don't think removal of powersave governor is good idea. Generally ondemand governor does great job but in some cases doesn't. For example when I play some films in mplayer ondemand sets frequency to max which is not needed, of course. Right, so we need to fix ondemand to be cleverer. Powersave governor is also good in case that you have bad fan in your laptop and you are going to compile some big source. Without powersave it is not possible (yes, it really happens :) ) Right, thermal management is similar to power management for the action but not for the policy. I don't think forcing the lowest speed setting is the correct way to fix this. If the laptop is running cool, why use the slowest speed? Matthew Garrett and I are working on a latency profile for power management, and having all these modules potentially loaded is bad. Comments? I think we should preserve ondemand and powersave governors (and potentialy others as Dave Jones wrote in this thread). Please don't drop them in favour of your project which might be generally better but I believe there are cases where current governors are better. Right, cheers for your feedback. In view of everybodies comments, what about the following: * Compile _into_ the kernel ondemand, performance, powersave and userspace. * Default to performance in the kernel rather than userspace * Build as a module conservative with the view of just fixing ondemand if there are any special use-cases that conservative is better at * Export the P and C state latency to userspace and let the system policy dictate the governor. For instance, even for machines that have a long latency for changing P states should be able to use ondemand if we want to save maximum power. How does that sound? Richard. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Mon, Jun 30, 2008 at 09:10:28AM +0200, Adam Tkac wrote: On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state I don't think removal of powersave governor is good idea. Generally ondemand governor does great job but in some cases doesn't. For example when I play some films in mplayer ondemand sets frequency to max which is not needed, of course. The same can be achieved by altering /sys/devices/system/cpu/*/cpufreq/scaling_max_freq, but it's still likely that you're consuming less power when ondemand is setting your frequency to max. An idle fast processor consumes less power than an active slow one. Powersave governor is also good in case that you have bad fan in your laptop and you are going to compile some big source. Without powersave it is not possible (yes, it really happens :) ) http://lkml.org/lkml/2008/6/16/100 I think we should preserve ondemand and powersave governors (and potentialy others as Dave Jones wrote in this thread). Please don't drop them in favour of your project which might be generally better but I believe there are cases where current governors are better. I'm open to indications as to what these are :) Powersave is semantically identical to ondemand with scaling_max_freq altered. Performance is semantically identical to ondemand with scaling_min_freq altered. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Monday 30 June 2008 05:54:32 am Richard Hughes wrote: Right, cheers for your feedback. In view of everybodies comments, what about the following: * Compile _into_ the kernel ondemand, performance, powersave and userspace. Sounds reasonable. * Default to performance in the kernel rather than userspace What's the difference? Both leave the cpu at its max speed all the time, unless the cpuspeed daemon gets started up in the userspace case. * Build as a module conservative with the view of just fixing ondemand if there are any special use-cases that conservative is better at * Export the P and C state latency to userspace and let the system policy dictate the governor. For instance, even for machines that have a long latency for changing P states should be able to use ondemand if we want to save maximum power. How does that sound? Mostly sane. System policy dictating governor over the ugliness we do in the cpuspeed init script would be nice. Even nicer would be if we could outright get rid of the initscript (not sure what people who need the cpuspeed daemon are to do in that case though). -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Fri, 27 Jun 2008 17:13:24 +0100 Richard Hughes [EMAIL PROTECTED] wrote: At the moment we set: # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m This is not ideal from a power-saving point of view. In an ideal world we would: * remove CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job on all workloads * remove CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace that needs this sort of control, and if we did, the latency would be horrible * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really want to be running this on all systems that support it * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed to something else by cpuspeed. You really don't want to be using USERSPACE at all. Matthew Garrett and I are working on a latency profile for power management, and having all these modules potentially loaded is bad. Comments? I totally agree with your suggestions. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
Richard Hughes wrote: In an ideal world we would: * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really want to be running this on all systems that support it * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed to something else by cpuspeed. You really don't want to be using USERSPACE at all. How can an administrator set a known constant frequency, so that the CPU might be able to deliver the same amount of work per unit time, over a span of half an hour? Some performance measurement and tuning is much simpler when this is so. -- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes [EMAIL PROTECTED] wrote: You really don't want to be using USERSPACE at all. seems like cpufreq-applet uses it ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Fri, 2008-06-27 at 22:56 +0200, drago01 wrote: On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes [EMAIL PROTECTED] wrote: On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes [EMAIL PROTECTED] wrote: You really don't want to be using USERSPACE at all. seems like cpufreq-applet uses it Sure, it shouldn't. If you're using userspace for thermal or latency reasons, then a setuid applet is totally the wrong way to achieve both of these :-) its not a setuid applet .. something seems to allow non root to do this (hal? consolekit? pam? udev? .. dunno) It currently uses consolehelper to get root. IMO, it shouldn't allow setting frequencies at all. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Fri, Jun 27, 2008 at 09:01:34PM +0100, Richard Hughes wrote: On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote: On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes [EMAIL PROTECTED] wrote: You really don't want to be using USERSPACE at all. seems like cpufreq-applet uses it Sure, it shouldn't. If you're using userspace for thermal or latency reasons, then a setuid applet is totally the wrong way to achieve both of these :-) Maybe we can just use these as loadable modules (i.e. not built default) rather than built-in and loaded by default. DaveJ, do these suggestions seem acceptable? Having the userspace governor built-in means absolutely nothing in terms of overhead, until something in userspace actually uses it. When the cpuspeed init script starts up, the first thing it does is check if the CPU is on the whitelist for using ondemand, and if so, it starts up ondemand. Not a single line of the userspace governor code gets run in this case. The only time the above isn't true is when the CPU isn't on that whitelist, when it's incapable of running ondemand, in which case we need to use.. ta-da... userspace, and then we start the cpuspeed process. Again, if you're seeing overhead from using userspace, it's due to your CPU being crap. There's nothing we can do about it. Whilst ondemand will load on some of these CPUs, the associated overhead of switching is very noticable on benchmarks. Even 'conservative' was too demanding for some of the challenged CPUs. 'crap' here doesn't mean really old stuff too. Any pre-centrino Intel CPU, any VIA CPU before Nehemiah generation, all mobile Athlons. We're using ondemand on all K8's too, but the first generation also sucked iirc, but we're just sucking it up because a) it makes the already convoluted startup script even more messy and b) no-one can remember which stepping/models were affected. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
