* [2.6 patch] make INPUT a bool @ 2006-02-14 15:22 Adrian Bunk 2006-02-14 18:14 ` Jan Engelhardt 2006-02-15 6:20 ` Dmitry Torokhov 0 siblings, 2 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-14 15:22 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-kernel, linux-input Make INPUT a bool. INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't make that much sense to make it modular. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- This patch was already sent on: - 3 Feb 2006 drivers/input/Kconfig | 2 +- drivers/input/input.c | 8 -------- 2 files changed, 1 insertion(+), 9 deletions(-) --- linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig.old 2006-02-03 22:42:18.000000000 +0100 +++ linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig 2006-02-03 22:42:29.000000000 +0100 @@ -5,7 +5,7 @@ menu "Input device support" config INPUT - tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED + bool "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED default y ---help--- Say Y here if you have any input device (mouse, keyboard, tablet, --- linux-2.6.16-rc1-mm5-full/drivers/input/input.c.old 2006-02-03 22:42:41.000000000 +0100 +++ linux-2.6.16-rc1-mm5-full/drivers/input/input.c 2006-02-03 22:47:44.000000000 +0100 @@ -984,12 +984,4 @@ return err; } -static void __exit input_exit(void) -{ - input_proc_exit(); - unregister_chrdev(INPUT_MAJOR, "input"); - class_unregister(&input_class); -} - subsys_initcall(input_init); -module_exit(input_exit); ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-14 15:22 [2.6 patch] make INPUT a bool Adrian Bunk @ 2006-02-14 18:14 ` Jan Engelhardt 2006-02-14 18:22 ` Adrian Bunk 2006-02-15 6:20 ` Dmitry Torokhov 1 sibling, 1 reply; 63+ messages in thread From: Jan Engelhardt @ 2006-02-14 18:14 UTC (permalink / raw) To: Adrian Bunk; +Cc: Dmitry Torokhov, linux-kernel, linux-input > >Make INPUT a bool. > >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't >make that much sense to make it modular. > modular would make sense to me - http://lkml.org/lkml/2006/1/25/106 >This patch was already sent on: >- 3 Feb 2006 Jan Engelhardt -- ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-14 18:14 ` Jan Engelhardt @ 2006-02-14 18:22 ` Adrian Bunk 2006-02-14 23:47 ` Adrian Bunk 2006-02-17 15:56 ` Jan Engelhardt 0 siblings, 2 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-14 18:22 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Dmitry Torokhov, linux-kernel, linux-input On Tue, Feb 14, 2006 at 07:14:21PM +0100, Jan Engelhardt wrote: > > > >Make INPUT a bool. > > > >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't > >make that much sense to make it modular. > > > modular would make sense to me - http://lkml.org/lkml/2006/1/25/106 >... I don't get your point: You don't need INPUT modular for hotplugging devices. In the normal EMBEDDED=n cases, users already do not have the choice of making INPUT modular. If someone is working in an environment that is that space limited that he sets EMBEDDED=y, why on earth should he enable module support that uses relatively much space in his kernel? > Jan Engelhardt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-14 18:22 ` Adrian Bunk @ 2006-02-14 23:47 ` Adrian Bunk 2006-02-17 15:56 ` Jan Engelhardt 1 sibling, 0 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-14 23:47 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Dmitry Torokhov, linux-kernel, linux-input On Tue, Feb 14, 2006 at 07:22:38PM +0100, Adrian Bunk wrote: > On Tue, Feb 14, 2006 at 07:14:21PM +0100, Jan Engelhardt wrote: > > > > > >Make INPUT a bool. > > > > > >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't > > >make that much sense to make it modular. > > > > > modular would make sense to me - http://lkml.org/lkml/2006/1/25/106 > >... > > I don't get your point: > > You don't need INPUT modular for hotplugging devices. > > In the normal EMBEDDED=n cases, users already do not have the choice of > making INPUT modular. > > If someone is working in an environment that is that space limited that > he sets EMBEDDED=y, why on earth should he enable module support that > uses relatively much space in his kernel? >... To back this with numbers: I'm usually using a non-modular kernel on my computer. This is the size difference between the same kernel with CONFIG_MODULES=y and CONFIG_MODULES=n: 3799589 vmlinux-with-modules 3447297 vmlinux-without-modules Yes, the kernel is becoming bigger by 10% only for supporting modules. Since the size increase is the space for the module support part of the kernel plus some additional space in many object files for stuff like EXPORT_SYMBOL's, the relative size increase is most likely even bigger for small kernels. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-14 18:22 ` Adrian Bunk 2006-02-14 23:47 ` Adrian Bunk @ 2006-02-17 15:56 ` Jan Engelhardt 2006-02-17 16:38 ` Adrian Bunk 1 sibling, 1 reply; 63+ messages in thread From: Jan Engelhardt @ 2006-02-17 15:56 UTC (permalink / raw) To: Adrian Bunk; +Cc: Dmitry Torokhov, linux-kernel, linux-input >> >Make INPUT a bool. >> > >> >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't >> >make that much sense to make it modular. >> > >> modular would make sense to me - http://lkml.org/lkml/2006/1/25/106 >>... > >I don't get your point: >You don't need INPUT modular for hotplugging devices. Well that is, if one happens to plug in a, say, USB keyboard. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-17 15:56 ` Jan Engelhardt @ 2006-02-17 16:38 ` Adrian Bunk 2006-02-20 3:33 ` Samuel Masham 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-17 16:38 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Dmitry Torokhov, linux-kernel, linux-input On Fri, Feb 17, 2006 at 04:56:51PM +0100, Jan Engelhardt wrote: > >> >Make INPUT a bool. > >> > > >> >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't > >> >make that much sense to make it modular. > >> > > >> modular would make sense to me - http://lkml.org/lkml/2006/1/25/106 > >>... > > > >I don't get your point: > >You don't need INPUT modular for hotplugging devices. > > Well that is, if one happens to plug in a, say, USB keyboard. Let me repeat the same sentence more boldly: YOU DO NOT NEED MODULES FOR HOTPLUGGING DEVICES. Please try to understand this sentence. And I've already given numbers why CONFIG_EMBEDDED=y and CONFIG_MODULES=y at the same time is insane. > Jan Engelhardt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-17 16:38 ` Adrian Bunk @ 2006-02-20 3:33 ` Samuel Masham 2006-02-20 13:28 ` Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Samuel Masham @ 2006-02-20 3:33 UTC (permalink / raw) To: Adrian Bunk; +Cc: Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input Hi Adrian, > And I've already given numbers why CONFIG_EMBEDDED=y and > CONFIG_MODULES=y at the same time is insane. >From your numbers this sounds true ... but actually you might want the modules to delay the init of the various hardware bits... Sometime boot-time is king and you just try and get back as much of the size costs as it takes... I think for EMBEDDED and MODULES is actually a very common case ... if somewhat odd. Samuel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-20 3:33 ` Samuel Masham @ 2006-02-20 13:28 ` Adrian Bunk 2006-02-22 1:34 ` Herbert Poetzl 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-20 13:28 UTC (permalink / raw) To: Samuel Masham; +Cc: Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > Hi Adrian, Hi Samuel, > > And I've already given numbers why CONFIG_EMBEDDED=y and > > CONFIG_MODULES=y at the same time is insane. > > >From your numbers this sounds true ... but actually you might want the > modules to delay the init of the various hardware bits... > > Sometime boot-time is king and you just try and get back as much of > the size costs as it takes... this is irrelevant since CONFIG_INPUT alone does not init any hardware. > I think for EMBEDDED and MODULES is actually a very common case ... if > somewhat odd. You are misunderstanding EMBEDDED. It does _not_ mean "this is an embedded device". It does mean "offer additional options for additional space savings". For an embedded system with relaxed space limits, EMBEDDED=n is the right choice. > Samuel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-20 13:28 ` Adrian Bunk @ 2006-02-22 1:34 ` Herbert Poetzl 2006-02-22 2:31 ` Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Herbert Poetzl @ 2006-02-22 1:34 UTC (permalink / raw) To: Adrian Bunk Cc: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > > > Hi Adrian, > > Hi Samuel, > > > > And I've already given numbers why CONFIG_EMBEDDED=y and > > > CONFIG_MODULES=y at the same time is insane. > > > > >From your numbers this sounds true ... but actually you might want the > > modules to delay the init of the various hardware bits... > > > > Sometime boot-time is king and you just try and get back as much of > > the size costs as it takes... > > this is irrelevant since CONFIG_INPUT alone does not init any hardware. > > > I think for EMBEDDED and MODULES is actually a very common case ... if > > somewhat odd. > > You are misunderstanding EMBEDDED. well, I suggested the following (or a similar) change some time ago (unfortunately I could not find it in the lkml archives, so it might have been lost) http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt best, Herbert > It does _not_ mean "this is an embedded device". > It does mean "offer additional options for additional space savings". > > For an embedded system with relaxed space limits, EMBEDDED=n is the > right choice. > > > Samuel > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 1:34 ` Herbert Poetzl @ 2006-02-22 2:31 ` Adrian Bunk 2006-02-22 2:44 ` Herbert Poetzl 2006-02-25 11:58 ` Geert Uytterhoeven 0 siblings, 2 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-22 2:31 UTC (permalink / raw) To: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote: > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > > > > > Hi Adrian, > > > > Hi Samuel, > > > > > > And I've already given numbers why CONFIG_EMBEDDED=y and > > > > CONFIG_MODULES=y at the same time is insane. > > > > > > >From your numbers this sounds true ... but actually you might want the > > > modules to delay the init of the various hardware bits... > > > > > > Sometime boot-time is king and you just try and get back as much of > > > the size costs as it takes... > > > > this is irrelevant since CONFIG_INPUT alone does not init any hardware. > > > > > I think for EMBEDDED and MODULES is actually a very common case ... if > > > somewhat odd. > > > > You are misunderstanding EMBEDDED. > > well, I suggested the following (or a similar) > change some time ago (unfortunately I could not > find it in the lkml archives, so it might have > been lost) > > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt That's not a good solution since EMBEDDED is really only about additional space savings - even if you are an "expert", there's no reason to enable EMBEDDED when building a kernel for systems with > 50 MB RAM. The better solution is IMHO an additional option: http://lkml.org/lkml/2006/2/7/93 http://lkml.org/lkml/2006/2/7/139 > best, > Herbert cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 2:31 ` Adrian Bunk @ 2006-02-22 2:44 ` Herbert Poetzl 2006-02-22 3:10 ` Adrian Bunk 2006-02-25 11:58 ` Geert Uytterhoeven 1 sibling, 1 reply; 63+ messages in thread From: Herbert Poetzl @ 2006-02-22 2:44 UTC (permalink / raw) To: Adrian Bunk Cc: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Wed, Feb 22, 2006 at 03:31:21AM +0100, Adrian Bunk wrote: > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote: > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > > > > > > > Hi Adrian, > > > > > > Hi Samuel, > > > > > > > > And I've already given numbers why CONFIG_EMBEDDED=y and > > > > > CONFIG_MODULES=y at the same time is insane. > > > > > > > > >From your numbers this sounds true ... but actually you might want the > > > > modules to delay the init of the various hardware bits... > > > > > > > > Sometime boot-time is king and you just try and get back as much of > > > > the size costs as it takes... > > > > > > this is irrelevant since CONFIG_INPUT alone does not init any hardware. > > > > > > > I think for EMBEDDED and MODULES is actually a very common case ... if > > > > somewhat odd. > > > > > > You are misunderstanding EMBEDDED. > > > > well, I suggested the following (or a similar) > > change some time ago (unfortunately I could not > > find it in the lkml archives, so it might have > > been lost) > > > > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt > > That's not a good solution since EMBEDDED is really only about > additional space savings - even if you are an "expert", there's no > reason to enable EMBEDDED when building a kernel for systems > with > 50 MB RAM. well, not sure everybody kows that ... config X86_P4_CLOCKMOD depends on EMBEDDED config VT_CONSOLE bool "Support for console on virtual terminal" if EMBEDDED config VGA_CONSOLE bool "VGA text console" if EMBEDDED config DNOTIFY bool "Dnotify support" if EMBEDDED config DEBUG_BUGVERBOSE bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED but, the patch was just considered a starting point so that folks would know _what_ EMBEDDED is currently used for ... > The better solution is IMHO an additional option: > http://lkml.org/lkml/2006/2/7/93 > http://lkml.org/lkml/2006/2/7/139 whatever, just get rid of the CONFIG_EMBEDDED everybody get's wrong and nobody really understands ... > > best, > > Herbert > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 2:44 ` Herbert Poetzl @ 2006-02-22 3:10 ` Adrian Bunk 2006-02-22 3:20 ` Dmitry Torokhov 2006-02-22 12:01 ` [2.6 patch] make INPUT a bool Herbert Poetzl 0 siblings, 2 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-22 3:10 UTC (permalink / raw) To: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote: > On Wed, Feb 22, 2006 at 03:31:21AM +0100, Adrian Bunk wrote: > > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote: > > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > > > > > > > > > Hi Adrian, > > > > > > > > Hi Samuel, > > > > > > > > > > And I've already given numbers why CONFIG_EMBEDDED=y and > > > > > > CONFIG_MODULES=y at the same time is insane. > > > > > > > > > > >From your numbers this sounds true ... but actually you might want the > > > > > modules to delay the init of the various hardware bits... > > > > > > > > > > Sometime boot-time is king and you just try and get back as much of > > > > > the size costs as it takes... > > > > > > > > this is irrelevant since CONFIG_INPUT alone does not init any hardware. > > > > > > > > > I think for EMBEDDED and MODULES is actually a very common case ... if > > > > > somewhat odd. > > > > > > > > You are misunderstanding EMBEDDED. > > > > > > well, I suggested the following (or a similar) > > > change some time ago (unfortunately I could not > > > find it in the lkml archives, so it might have > > > been lost) > > > > > > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt > > > > That's not a good solution since EMBEDDED is really only about > > additional space savings - even if you are an "expert", there's no > > reason to enable EMBEDDED when building a kernel for systems > > with > 50 MB RAM. > > well, not sure everybody kows that ... > > config X86_P4_CLOCKMOD > depends on EMBEDDED This one is an x86_64 only issue, and yes, it's wrong. > config VT_CONSOLE > bool "Support for console on virtual terminal" if EMBEDDED Looks OK. > config VGA_CONSOLE > bool "VGA text console" if EMBEDDED Looks OK. > config DNOTIFY > bool "Dnotify support" if EMBEDDED Looks OK. > config DEBUG_BUGVERBOSE > bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED Looks OK. > but, the patch was just considered a starting point > so that folks would know _what_ EMBEDDED is currently > used for ... Except for the X86_P4_CLOCKMOD case, all of your examples are correct usages of EMBEDDED. > > The better solution is IMHO an additional option: > > http://lkml.org/lkml/2006/2/7/93 > > http://lkml.org/lkml/2006/2/7/139 > > whatever, just get rid of the CONFIG_EMBEDDED everybody > get's wrong and nobody really understands ... No, the EMBEDDED semantics shouldn't be changed and most people get it right. Naming it EXPERT as you suggested would make it even worse. We could name it SHOW_OPTIONS_FOR_ADDITIONAL_SPACE_SAVINGS_IF_YOU_REALLY_KNOW_WHAT_YOU_ARE_DOING, but unless someone comes up with a name that is both short and significantely better than EMBEDDED I don't see a reason for changing it. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 3:10 ` Adrian Bunk @ 2006-02-22 3:20 ` Dmitry Torokhov 2006-02-23 19:59 ` Status of X86_P4_CLOCKMOD? Adrian Bunk 2006-02-22 12:01 ` [2.6 patch] make INPUT a bool Herbert Poetzl 1 sibling, 1 reply; 63+ messages in thread From: Dmitry Torokhov @ 2006-02-22 3:20 UTC (permalink / raw) To: Adrian Bunk Cc: Samuel Masham, Jan Engelhardt, linux-kernel, linux-input, Andrew Morton On Tuesday 21 February 2006 22:10, Adrian Bunk wrote: > On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote: > > > > config X86_P4_CLOCKMOD > > depends on EMBEDDED > > This one is an x86_64 only issue, and yes, it's wrong. That's for P4, not X86_64... And since P4 clock modulation does not provide almost any energy savings it was "hidden" under embedded. -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* Status of X86_P4_CLOCKMOD? 2006-02-22 3:20 ` Dmitry Torokhov @ 2006-02-23 19:59 ` Adrian Bunk 2006-02-23 20:41 ` Dave Jones 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-23 19:59 UTC (permalink / raw) To: Dmitry Torokhov, davej, Zwane Mwaikambo Cc: Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Tue, Feb 21, 2006 at 10:20:04PM -0500, Dmitry Torokhov wrote: > On Tuesday 21 February 2006 22:10, Adrian Bunk wrote: > > On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote: > > > > > > config X86_P4_CLOCKMOD > > > depends on EMBEDDED > > > > This one is an x86_64 only issue, and yes, it's wrong. > > That's for P4, not X86_64... And since P4 clock modulation does not provide > almost any energy savings it was "hidden" under embedded. But the EMBEDDED dependency is only on x86_64: arch/i386/kernel/cpu/cpufreq/Kconfig: config X86_P4_CLOCKMOD tristate "Intel Pentium 4 clock modulation" select CPU_FREQ_TABLE help arch/x86_64/kernel/cpufreq/Kconfig: config X86_P4_CLOCKMOD tristate "Intel Pentium 4 clock modulation" depends on EMBEDDED help And if the option is mostly useless, what is it good for? > Dmitry cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 19:59 ` Status of X86_P4_CLOCKMOD? Adrian Bunk @ 2006-02-23 20:41 ` Dave Jones 2006-02-23 23:15 ` Andi Kleen ` (2 more replies) 0 siblings, 3 replies; 63+ messages in thread From: Dave Jones @ 2006-02-23 20:41 UTC (permalink / raw) To: Adrian Bunk Cc: Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > config X86_P4_CLOCKMOD > > > > depends on EMBEDDED > > > > > > This one is an x86_64 only issue, and yes, it's wrong. > > > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > almost any energy savings it was "hidden" under embedded. > > But the EMBEDDED dependency is only on x86_64: > > arch/i386/kernel/cpu/cpufreq/Kconfig: > config X86_P4_CLOCKMOD > tristate "Intel Pentium 4 clock modulation" > select CPU_FREQ_TABLE > help > > arch/x86_64/kernel/cpufreq/Kconfig: > config X86_P4_CLOCKMOD > tristate "Intel Pentium 4 clock modulation" > depends on EMBEDDED > help > > And if the option is mostly useless, what is it good for? It's sometimes useful in cases where the target CPU doesn't have any better option (Speedstep/Powernow). The big misconception is that it somehow saves power & increases battery life. Not so. All it does is 'not do work so often'. The upside of this is that in some situations, we generate less heat this way. It's really of limited practical use, but occasionally, we find some users that do find it handy. (One case I heard was someone with a server farm that generated lots of heat, but at nighttime, he could throttle that back, which resulted in a drop in overall temperature in the serverroom -- no numbers to back it up though, just anecdotes). As to the difference of EMBEDDED.. on 32bit, there's a lot more systems without speedstep/powernow, so it makes more sense to make it more widely available. Nearly all AMD64/EM64T have some form of speed-scaling which is more effective than p4-clockmod, which is why I assume it's set that way. Andi can probably confirm the thinking on that one, as I think he added it when x86-64 first started supporting cpufreq. Dave ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 20:41 ` Dave Jones @ 2006-02-23 23:15 ` Andi Kleen 2006-02-23 23:33 ` Adrian Bunk 2006-02-25 1:57 ` Johannes Stezenbach 2006-02-28 19:46 ` Matt Mackall 2 siblings, 1 reply; 63+ messages in thread From: Andi Kleen @ 2006-02-23 23:15 UTC (permalink / raw) To: Dave Jones Cc: Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Thursday 23 February 2006 21:41, Dave Jones wrote: > It's really of limited practical use, but occasionally, we find > some users that do find it handy. (One case I heard was someone > with a server farm that generated lots of heat, but at nighttime, > he could throttle that back, which resulted in a drop in overall > temperature in the serverroom -- no numbers to back it up though, > just anecdotes). Perhaps they should just turn some computers off over night then. Another drawback is that adds very long latencies. e.g. when it is enabled you can really end up with desktops where the mouse doesn't react for a very visible to humans delay. And it'll mess up kernel timing in general. > As to the difference of EMBEDDED.. on 32bit, there's a lot more > systems without speedstep/powernow, so it makes more sense to > make it more widely available. Nearly all AMD64/EM64T have > some form of speed-scaling which is more effective than p4-clockmod, > which is why I assume it's set that way. > > Andi can probably confirm the thinking on that one, as I think > he added it when x86-64 first started supporting cpufreq. It should IMHO depend on EMBEDDED on i386 too because the uses are extremly specialized (if there are any) and most users setting it probably set it by mistake because they misunderstand it. -Andi ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 23:15 ` Andi Kleen @ 2006-02-23 23:33 ` Adrian Bunk 2006-02-23 23:55 ` Andi Kleen 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-23 23:33 UTC (permalink / raw) To: Andi Kleen Cc: Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Fri, Feb 24, 2006 at 12:15:59AM +0100, Andi Kleen wrote: > On Thursday 23 February 2006 21:41, Dave Jones wrote: >... > > As to the difference of EMBEDDED.. on 32bit, there's a lot more > > systems without speedstep/powernow, so it makes more sense to > > make it more widely available. Nearly all AMD64/EM64T have > > some form of speed-scaling which is more effective than p4-clockmod, > > which is why I assume it's set that way. > > > > Andi can probably confirm the thinking on that one, as I think > > he added it when x86-64 first started supporting cpufreq. > > It should IMHO depend on EMBEDDED on i386 too because > the uses are extremly specialized (if there are any) and most users setting it > probably set it by mistake because they misunderstand it. EMBEDDED is the wrong option, since the semantics of embedded is "show more options to allow additional space savings". It is not and should not be abused as an option to hide random options from users. Currently, EXPERIMENTAL is nearer to what suits X86_P4_CLOCKMOD, and it seems we really need an ADVANCED_USER option for such options. > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 23:33 ` Adrian Bunk @ 2006-02-23 23:55 ` Andi Kleen 2006-02-24 2:39 ` Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Andi Kleen @ 2006-02-23 23:55 UTC (permalink / raw) To: Adrian Bunk Cc: Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Friday 24 February 2006 00:33, Adrian Bunk wrote: > EMBEDDED is the wrong option, since the semantics of embedded is "show > more options to allow additional space savings". It is not and should > not be abused as an option to hide random options from users. I disagree. And I originally added most EMBEDDED users to the kernel. The purpose I added it for was to hide options that only useful for a very limited userbase but cause big or subtle trouble when set wrong. P4_CLOCKMOD clearly qualifies. -Andi ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 23:55 ` Andi Kleen @ 2006-02-24 2:39 ` Adrian Bunk 2006-02-24 2:42 ` Andi Kleen 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-24 2:39 UTC (permalink / raw) To: Andi Kleen Cc: Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Fri, Feb 24, 2006 at 12:55:30AM +0100, Andi Kleen wrote: > On Friday 24 February 2006 00:33, Adrian Bunk wrote: > > > EMBEDDED is the wrong option, since the semantics of embedded is "show > > more options to allow additional space savings". It is not and should > > not be abused as an option to hide random options from users. > > I disagree. And I originally added most EMBEDDED users to the kernel. > The purpose I added it for was to hide options that only useful > for a very limited userbase but cause big or subtle trouble when set > wrong. P4_CLOCKMOD clearly qualifies. This matches neither the description of the EMBEDDED option nor all other usages in the kernel I have seen until now. We need an additional option for such cases, but overloading EMBEDDED with more than one meaning is definitely not a good idea. > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-24 2:39 ` Adrian Bunk @ 2006-02-24 2:42 ` Andi Kleen 2006-02-24 17:33 ` Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Andi Kleen @ 2006-02-24 2:42 UTC (permalink / raw) To: Adrian Bunk Cc: Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Friday 24 February 2006 03:39, Adrian Bunk wrote: > We need an additional option for such cases, but overloading EMBEDDED > with more than one meaning is definitely not a good idea. I think it works just fine. -Andi ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-24 2:42 ` Andi Kleen @ 2006-02-24 17:33 ` Adrian Bunk 0 siblings, 0 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-24 17:33 UTC (permalink / raw) To: Andi Kleen Cc: Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Fri, Feb 24, 2006 at 03:42:02AM +0100, Andi Kleen wrote: > On Friday 24 February 2006 03:39, Adrian Bunk wrote: > > > We need an additional option for such cases, but overloading EMBEDDED > > with more than one meaning is definitely not a good idea. > > I think it works just fine. It works in the way that users don't see this option. Both for this purpose, BROKEN or even simply removing the option would work equally well... > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 20:41 ` Dave Jones 2006-02-23 23:15 ` Andi Kleen @ 2006-02-25 1:57 ` Johannes Stezenbach 2006-02-25 4:24 ` Dave Jones 2006-02-25 4:27 ` Andi Kleen 2006-02-28 19:46 ` Matt Mackall 2 siblings, 2 replies; 63+ messages in thread From: Johannes Stezenbach @ 2006-02-25 1:57 UTC (permalink / raw) To: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Thu, Feb 23, 2006, Dave Jones wrote: > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > And if the option is mostly useless, what is it good for? > > It's sometimes useful in cases where the target CPU doesn't have any better > option (Speedstep/Powernow). The big misconception is that it > somehow saves power & increases battery life. Not so. > All it does is 'not do work so often'. The upside of this is > that in some situations, we generate less heat this way. Doesn't less heat imply less power consumption? Anyway, I have P4 in my desktop machine, and the reason why I tried to use P4 clock modulation was to reduce fan noise, and save some energy. And yes, fan noise was reduced. The reason why I turned it off again was that I couldn't find any governor or userspace daemon that would work in a sensible way with the high latency of the P4 clock modulation. What I think could work: - after some minutes of idling without user activity go into lowest power mode (could be triggered from xscreensaver) - at the slightest hint of user activity or CPU load jump back to max performance mode (- optionally use intermediate clock mod steps for non-interactive loads, but I'm not convinced it's worth it) P4 clockmod certainly sucks compared to Speedstep, but IMHO it is still potentially useful for the average desktop PC user (at least those many who let their PCs run 24/7, but 90% idle and unused). Johannes ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 1:57 ` Johannes Stezenbach @ 2006-02-25 4:24 ` Dave Jones 2006-02-25 12:53 ` Johannes Stezenbach 2006-02-25 4:27 ` Andi Kleen 1 sibling, 1 reply; 63+ messages in thread From: Dave Jones @ 2006-02-25 4:24 UTC (permalink / raw) To: Johannes Stezenbach, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Sat, Feb 25, 2006 at 02:57:22AM +0100, Johannes Stezenbach wrote: > On Thu, Feb 23, 2006, Dave Jones wrote: > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > And if the option is mostly useless, what is it good for? > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > option (Speedstep/Powernow). The big misconception is that it > > somehow saves power & increases battery life. Not so. > > All it does is 'not do work so often'. The upside of this is > > that in some situations, we generate less heat this way. > > Doesn't less heat imply less power consumption? Not really. The only energy you're saving is that your CPU fan will turn slightly slower, which is probably going to be < 1W of difference. Generated heat drop in a large room of servers *may* mean the aircon has less to do, but I'd be surprised if it made a noticable difference. > - after some minutes of idling without user activity > go into lowest power mode (could be triggered > from xscreensaver) > - at the slightest hint of user activity or CPU load jump > back to max performance mode > (- optionally use intermediate clock mod steps for > non-interactive loads, but I'm not convinced it's > worth it) You should be able to modify cpuspeed or some other userspace governor to do this quite easily. Dave ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 4:24 ` Dave Jones @ 2006-02-25 12:53 ` Johannes Stezenbach 2006-02-27 21:17 ` Wes Felter 0 siblings, 1 reply; 63+ messages in thread From: Johannes Stezenbach @ 2006-02-25 12:53 UTC (permalink / raw) To: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Fri, Feb 24, 2006, Dave Jones wrote: > On Sat, Feb 25, 2006 at 02:57:22AM +0100, Johannes Stezenbach wrote: > > On Thu, Feb 23, 2006, Dave Jones wrote: > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > And if the option is mostly useless, what is it good for? > > > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > > option (Speedstep/Powernow). The big misconception is that it > > > somehow saves power & increases battery life. Not so. > > > All it does is 'not do work so often'. The upside of this is > > > that in some situations, we generate less heat this way. > > > > Doesn't less heat imply less power consumption? > > Not really. The only energy you're saving is that your CPU fan > will turn slightly slower, which is probably going to be < 1W > of difference. I thought the fan turns slower because the CPU generates less heat, which in turn is because it consumes less electrical energy. If someone has done measurements I'd be interested to know the numbers about the actual power savings which can be achieved by using P4 clock mod. I don't expect it to be much, but I bet it's more than 1W. Johannes ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 12:53 ` Johannes Stezenbach @ 2006-02-27 21:17 ` Wes Felter 0 siblings, 0 replies; 63+ messages in thread From: Wes Felter @ 2006-02-27 21:17 UTC (permalink / raw) To: linux-kernel; +Cc: cpufreq Johannes Stezenbach wrote: > If someone has done measurements I'd be interested to > know the numbers about the actual power savings which > can be achieved by using P4 clock mod. I don't expect > it to be much, but I bet it's more than 1W. Clock modulation can reduce power by 40W on a 3.6GHz Xeon when the system is running a high-power application (e.g. Linpack). (It also reduces performance by a factor of 6-10). Clock modulation saves no power at all during idle. Wes Felter - wesley@felter.org ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 1:57 ` Johannes Stezenbach 2006-02-25 4:24 ` Dave Jones @ 2006-02-25 4:27 ` Andi Kleen 2006-02-25 12:53 ` Adrian Bunk 2006-02-25 13:05 ` Johannes Stezenbach 1 sibling, 2 replies; 63+ messages in thread From: Andi Kleen @ 2006-02-25 4:27 UTC (permalink / raw) To: Johannes Stezenbach Cc: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote: > On Thu, Feb 23, 2006, Dave Jones wrote: > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > And if the option is mostly useless, what is it good for? > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > option (Speedstep/Powernow). The big misconception is that it > > somehow saves power & increases battery life. Not so. > > All it does is 'not do work so often'. The upside of this is > > that in some situations, we generate less heat this way. > > Doesn't less heat imply less power consumption? Not in this case no. > P4 clockmod certainly sucks compared to Speedstep, > but IMHO it is still potentially useful for the average > desktop PC user (at least those many who let their PCs > run 24/7, but 90% idle and unused). I don't think so no. The latencies make it unusable. -Andi ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 4:27 ` Andi Kleen @ 2006-02-25 12:53 ` Adrian Bunk 2006-02-25 13:28 ` Dominik Brodowski 2006-02-25 13:36 ` Andi Kleen 2006-02-25 13:05 ` Johannes Stezenbach 1 sibling, 2 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-25 12:53 UTC (permalink / raw) To: Andi Kleen Cc: Johannes Stezenbach, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Sat, Feb 25, 2006 at 05:27:01AM +0100, Andi Kleen wrote: > On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote: > > On Thu, Feb 23, 2006, Dave Jones wrote: > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > And if the option is mostly useless, what is it good for? > > > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > > option (Speedstep/Powernow). The big misconception is that it > > > somehow saves power & increases battery life. Not so. > > > All it does is 'not do work so often'. The upside of this is > > > that in some situations, we generate less heat this way. > > > > Doesn't less heat imply less power consumption? > > Not in this case no. >... Sorry for the dumb question, but how could this work physically? If a computer produces less heat with the same power consumption, what happens with the other energy? > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 12:53 ` Adrian Bunk @ 2006-02-25 13:28 ` Dominik Brodowski 2006-02-26 11:12 ` Pavel Machek 2006-02-26 20:39 ` Johannes Stezenbach 2006-02-25 13:36 ` Andi Kleen 1 sibling, 2 replies; 63+ messages in thread From: Dominik Brodowski @ 2006-02-25 13:28 UTC (permalink / raw) To: Adrian Bunk Cc: Andi Kleen, Johannes Stezenbach, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Sat, Feb 25, 2006 at 01:53:26PM +0100, Adrian Bunk wrote: > > > Doesn't less heat imply less power consumption? > > > > Not in this case no. > >... > > Sorry for the dumb question, but how could this work physically? > > If a computer produces less heat with the same power consumption, what > happens with the other energy? No. Let's do the math (again), and (again) for the actual values of an Intel Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of physics, logic and mathematics apply to _all_ processors. Power consumption in idle state C2 (Stop-Grant state) 7.3 W Power consumption when "skipping instructions" because of throttling (Stop-Grant state) 7.3 W Power consumption when doing work 22.0 W This means that if the processor idle percentage is _larger_ than (1 - throttling rate), throttling has no effect at all. Now, let's assume there is some work for the CPU to do which keeps it busy for one second @ 1.4 GHz. How much energy is needed to get this work done? 0% throttling: 22 Ws (1s) 25% throttling: 24 Ws (1.3s) 50% throttling: 29 Ws (2s) 75% throttling: 44 Ws (4s) Now let's also assume there is nothing else to do during a span of four seconds: then, independent of the throttling setting, the CPU power consumption is 44 Ws for these four seconds. However: for the 75% throttling state, the CPU only produces 11 W of heat _all the time_ -- this means, the fan or air conditioning must only consider 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool that sufficiently, the fan _may_ need to run faster, which consumes more energy than is saved by only having to cool 7.3 W (instead of 11W) the other three seconds. So: P4-clockmod style throttling only makes sense if either a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or b) the load varies significantly over time in a manner which has effect on the fan, and where the latency induced by throttling doesn't matter. Dominik ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 13:28 ` Dominik Brodowski @ 2006-02-26 11:12 ` Pavel Machek 2006-02-26 20:39 ` Johannes Stezenbach 1 sibling, 0 replies; 63+ messages in thread From: Pavel Machek @ 2006-02-26 11:12 UTC (permalink / raw) To: Adrian Bunk, Andi Kleen, Johannes Stezenbach, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq Hi! > > > Not in this case no. > > >... > > > > Sorry for the dumb question, but how could this work physically? > > > > If a computer produces less heat with the same power consumption, what > > happens with the other energy? > > No. Let's do the math (again), and (again) for the actual values of an Intel > Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of > physics, logic and mathematics apply to _all_ processors. > > Power consumption in idle state C2 (Stop-Grant state) 7.3 W > Power consumption when "skipping instructions" > because of throttling (Stop-Grant state) 7.3 W > > Power consumption when doing work 22.0 W > > > This means that if the processor idle percentage is _larger_ than (1 - > throttling rate), throttling has no effect at all. > > > Now, let's assume there is some work for the CPU to do which keeps it busy > for one second @ 1.4 GHz. How much energy is needed to get this work done? > > 0% throttling: 22 Ws (1s) > 25% throttling: 24 Ws (1.3s) > 50% throttling: 29 Ws (2s) > 75% throttling: 44 Ws (4s) > > > Now let's also assume there is nothing else to do during a span of four > seconds: then, independent of the throttling setting, the CPU power > consumption is 44 Ws for these four seconds. > > > However: for the 75% throttling state, the CPU only produces 11 W of heat > _all the time_ -- this means, the fan or air conditioning must only consider > 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool > that sufficiently, the fan _may_ need to run faster, which consumes more > energy than is saved by only having to cool 7.3 W (instead of 11W) the other > three seconds. > > > So: P4-clockmod style throttling only makes sense if either > > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or > > b) the load varies significantly over time in a manner which has effect on > the fan, and where the latency induced by throttling doesn't matter. c) your load is something like game of doom, where you want to play for half an hour with least power consumed. You don't really need 1000 fps, 100 fps is enough. Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 13:28 ` Dominik Brodowski 2006-02-26 11:12 ` Pavel Machek @ 2006-02-26 20:39 ` Johannes Stezenbach 2006-02-26 20:55 ` Dominik Brodowski 1 sibling, 1 reply; 63+ messages in thread From: Johannes Stezenbach @ 2006-02-26 20:39 UTC (permalink / raw) To: Adrian Bunk, Andi Kleen, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Sat, Feb 25, 2006 at, Dominik Brodowski wrote: > On Sat, Feb 25, 2006 at 01:53:26PM +0100, Adrian Bunk wrote: > > > > Doesn't less heat imply less power consumption? > > > > > > Not in this case no. > > >... > > > > Sorry for the dumb question, but how could this work physically? > > > > If a computer produces less heat with the same power consumption, what > > happens with the other energy? > > No. Let's do the math (again), and (again) for the actual values of an Intel > Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of > physics, logic and mathematics apply to _all_ processors. Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find anything substantial with google.) Especially C2 vs. C2 + throttling? Because the way I remember having read somewhere, the idle (C2) power consumption of the P4 is significantly higher than with the Pentium(R) M. > Power consumption in idle state C2 (Stop-Grant state) 7.3 W > Power consumption when "skipping instructions" > because of throttling (Stop-Grant state) 7.3 W > > Power consumption when doing work 22.0 W > > > This means that if the processor idle percentage is _larger_ than (1 - > throttling rate), throttling has no effect at all. On a Pentium(R) M, but how about P4? The two have very different architectures, don't they? > Now, let's assume there is some work for the CPU to do which keeps it busy > for one second @ 1.4 GHz. How much energy is needed to get this work done? > > 0% throttling: 22 Ws (1s) > 25% throttling: 24 Ws (1.3s) > 50% throttling: 29 Ws (2s) > 75% throttling: 44 Ws (4s) > > > Now let's also assume there is nothing else to do during a span of four > seconds: then, independent of the throttling setting, the CPU power > consumption is 44 Ws for these four seconds. > > > However: for the 75% throttling state, the CPU only produces 11 W of heat > _all the time_ -- this means, the fan or air conditioning must only consider > 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool > that sufficiently, the fan _may_ need to run faster, which consumes more > energy than is saved by only having to cool 7.3 W (instead of 11W) the other > three seconds. This is all fine, but why would anyone use throttling when the CPU has work to do (except for thermal emergency throttling)? > So: P4-clockmod style throttling only makes sense if either > > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or > > b) the load varies significantly over time in a manner which has effect on > the fan, and where the latency induced by throttling doesn't matter. Maybe my previous mails were not clear enough: The goal is to reduce idle power consumption (and by that fan noise). The PC is running but is idle, e.g just listening for possible incoming jabber messages or whatever. When I experimented with P4-clockmod some time ago, I observed that the fan noise was reduced when I left the box run idle with clockmod set to maximum throttling. I thought this was a good thing. Anyway, 2.6.16-rc4 p4-clockmod driver doesn't work with my CPU anymore (booted with cpufreq.debug=7): CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09 Checking 'hlt' instruction... OK. ... cpufreq-core: trying to register driver p4-clockmod cpufreq-core: adding CPU 0 p4-clockmod: has errata -- disabling frequencies lower than 2ghz speedstep-lib: x86: f, model: 2 speedstep-lib: ebx value is 9, x86_mask is 9 speedstep-lib: P4 - MSR_EBC_FREQUENCY_ID: 0xd12000d 0x0 speedstep-lib: P4 - FSB 200000 kHz; Multiplier 13; Speed 2600000 kHz freq-table: setting show_table for cpu 0 to b04be620 freq-table: table entry 0 is invalid, skipping freq-table: table entry 1 is invalid, skipping freq-table: table entry 2 is invalid, skipping freq-table: table entry 3 is invalid, skipping freq-table: table entry 4 is invalid, skipping freq-table: table entry 5 is invalid, skipping freq-table: table entry 6 is invalid, skipping freq-table: table entry 7 is invalid, skipping freq-table: table entry 8 is invalid, skipping cpufreq-core: initialization failed cpufreq-core: no CPU initialized for driver p4-clockmod cpufreq-core: unregistering CPU 0 Johannes ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-26 20:39 ` Johannes Stezenbach @ 2006-02-26 20:55 ` Dominik Brodowski 2006-02-26 23:37 ` Johannes Stezenbach 0 siblings, 1 reply; 63+ messages in thread From: Dominik Brodowski @ 2006-02-26 20:55 UTC (permalink / raw) To: Johannes Stezenbach, Adrian Bunk, Andi Kleen, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq Hi, On Sun, Feb 26, 2006 at 09:39:41PM +0100, Johannes Stezenbach wrote: > > No. Let's do the math (again), and (again) for the actual values of an Intel > > Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of > > physics, logic and mathematics apply to _all_ processors. > > Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find > anything substantial with google.) Especially C2 vs. C2 + throttling? > Because the way I remember having read somewhere, the idle > (C2) power consumption of the P4 is significantly higher > than with the Pentium(R) M. Unfortunately, I do not have these numbers present. You can check the processor specification sheets at Intel's website, though. > > Power consumption in idle state C2 (Stop-Grant state) 7.3 W > > Power consumption when "skipping instructions" > > because of throttling (Stop-Grant state) 7.3 W > > > > Power consumption when doing work 22.0 W > > > > > > This means that if the processor idle percentage is _larger_ than (1 - > > throttling rate), throttling has no effect at all. > > On a Pentium(R) M, but how about P4? The two have very different > architectures, don't they? They have different architectures, but again -- AFAIK -- throttling means STPCLK is stopped, which is equivalent to the Stop-Grant state. And that's what's usually entered in C2-type idle sleep. > > However: for the 75% throttling state, the CPU only produces 11 W of heat > > _all the time_ -- this means, the fan or air conditioning must only consider > > 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool > > that sufficiently, the fan _may_ need to run faster, which consumes more > > energy than is saved by only having to cool 7.3 W (instead of 11W) the other > > three seconds. > > This is all fine, but why would anyone use throttling when the > CPU has work to do (except for thermal emergency throttling)? That's exactly the opposite of what you should do, if idling works at least reasonably well: only enter throttling if the CPU has some substancial workload. > > So: P4-clockmod style throttling only makes sense if either > > > > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or > > > > b) the load varies significantly over time in a manner which has effect on > > the fan, and where the latency induced by throttling doesn't matter. > > Maybe my previous mails were not clear enough: The goal is to > reduce idle power consumption (and by that fan noise). The PC > is running but is idle, e.g just listening for possible incoming > jabber messages or whatever. Most probably, the idle handler can't make use of the Stop-Grant state (C2) here, so this is case a) noted above. > p4-clockmod: has errata -- disabling frequencies lower than 2ghz Dominik ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-26 20:55 ` Dominik Brodowski @ 2006-02-26 23:37 ` Johannes Stezenbach 0 siblings, 0 replies; 63+ messages in thread From: Johannes Stezenbach @ 2006-02-26 23:37 UTC (permalink / raw) To: Dominik Brodowski Cc: Adrian Bunk, Andi Kleen, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Sun, Feb 26, 2006, Dominik Brodowski wrote: > On Sun, Feb 26, 2006 at 09:39:41PM +0100, Johannes Stezenbach wrote: > > > > Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find > > anything substantial with google.) Especially C2 vs. C2 + throttling? > > Because the way I remember having read somewhere, the idle > > (C2) power consumption of the P4 is significantly higher > > than with the Pentium(R) M. > > Unfortunately, I do not have these numbers present. You can check the > processor specification sheets at Intel's website, though. Went to the Intel(R) website, searched for half an hour, found many docs but none that gives useful information about this, gave up. :-( > > > So: P4-clockmod style throttling only makes sense if either > > > > > > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or > > > > Maybe my previous mails were not clear enough: The goal is to > > reduce idle power consumption (and by that fan noise). The PC > > is running but is idle, e.g just listening for possible incoming > > jabber messages or whatever. > > Most probably, the idle handler can't make use of the Stop-Grant state (C2) > here, so this is case a) noted above. Hm. Thanks, Johannes ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 12:53 ` Adrian Bunk 2006-02-25 13:28 ` Dominik Brodowski @ 2006-02-25 13:36 ` Andi Kleen 1 sibling, 0 replies; 63+ messages in thread From: Andi Kleen @ 2006-02-25 13:36 UTC (permalink / raw) To: Adrian Bunk Cc: Johannes Stezenbach, Dave Jones, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Saturday 25 February 2006 13:53, Adrian Bunk wrote: On Sat, Feb 25, 2006 at 05:27:01AM +0100, Andi Kleen wrote: > > On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote: > > > On Thu, Feb 23, 2006, Dave Jones wrote: > > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > > And if the option is mostly useless, what is it good for? > > > > > > > > It's sometimes useful in cases where the target CPU doesn't have any > > > > better option (Speedstep/Powernow). The big misconception is that it > > > > somehow saves power & increases battery life. Not so. > > > > All it does is 'not do work so often'. The upside of this is > > > > that in some sit> uations, we generate less heat this way. > > > > > > Doesn't less heat imply less power consumption? > > > > Not in this case no. > >... > > Sorry for the dumb question, but how could this work physically? > > If a computer produces less heat with the same power consumption, what > happens with the other energy? It's consumed over a longer time. In throttling mode the CPU skips doing work on clock ticks. This temporarily lowers the local heat that comes from switching transistors, but if the system has some computation to do it will take longer to do it until the machine can go to idle again and do real power saving. This means on a global scale you're not saving anything, in fact you're wasting more power. There are sometimes secondary effects like the air condition of your server room may consume less power if the peak heat is lower, but they likely only apply in very specialized circumstances. It's basically only a last measure that the CPU tries to cool itself down a bit before forcibly shutting down. It's also not really designed to be used in normal operation, so you end up with problems like TSC timing being wrong or extremly long user visible latencies to switch back to normal operation. -Andi ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-25 4:27 ` Andi Kleen 2006-02-25 12:53 ` Adrian Bunk @ 2006-02-25 13:05 ` Johannes Stezenbach 1 sibling, 0 replies; 63+ messages in thread From: Johannes Stezenbach @ 2006-02-25 13:05 UTC (permalink / raw) To: Andi Kleen Cc: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Sat, Feb 25, 2006, Andi Kleen wrote: > On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote: > > P4 clockmod certainly sucks compared to Speedstep, > > but IMHO it is still potentially useful for the average > > desktop PC user (at least those many who let their PCs > > run 24/7, but 90% idle and unused). > > I don't think so no. The latencies make it unusable. I tried to explain that I think one can use it in a way so the latencies are not a big issue. One must just accept that it needs different policy than Speedstep etc. Johannes ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-23 20:41 ` Dave Jones 2006-02-23 23:15 ` Andi Kleen 2006-02-25 1:57 ` Johannes Stezenbach @ 2006-02-28 19:46 ` Matt Mackall 2006-02-28 20:09 ` Dave Jones 2 siblings, 1 reply; 63+ messages in thread From: Matt Mackall @ 2006-02-28 19:46 UTC (permalink / raw) To: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote: > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > > > config X86_P4_CLOCKMOD > > > > > depends on EMBEDDED > > > > > > > > This one is an x86_64 only issue, and yes, it's wrong. > > > > > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > > almost any energy savings it was "hidden" under embedded. > > > > But the EMBEDDED dependency is only on x86_64: > > > > arch/i386/kernel/cpu/cpufreq/Kconfig: > > config X86_P4_CLOCKMOD > > tristate "Intel Pentium 4 clock modulation" > > select CPU_FREQ_TABLE > > help > > > > arch/x86_64/kernel/cpufreq/Kconfig: > > config X86_P4_CLOCKMOD > > tristate "Intel Pentium 4 clock modulation" > > depends on EMBEDDED > > help > > > > And if the option is mostly useless, what is it good for? > > It's sometimes useful in cases where the target CPU doesn't have any better > option (Speedstep/Powernow). The big misconception is that it > somehow saves power & increases battery life. Not so. > All it does is 'not do work so often'. The upside of this is > that in some situations, we generate less heat this way. This is perplexing. Less heat equals less power usage according to the laws of thermodynamics. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 19:46 ` Matt Mackall @ 2006-02-28 20:09 ` Dave Jones 2006-02-28 20:19 ` Dmitry Torokhov 2006-02-28 20:47 ` Matt Mackall 0 siblings, 2 replies; 63+ messages in thread From: Dave Jones @ 2006-02-28 20:09 UTC (permalink / raw) To: Matt Mackall Cc: Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote: > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote: > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > > > > > config X86_P4_CLOCKMOD > > > > > > depends on EMBEDDED > > > > > > > > > > This one is an x86_64 only issue, and yes, it's wrong. > > > > > > > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > > > almost any energy savings it was "hidden" under embedded. > > > > > > But the EMBEDDED dependency is only on x86_64: > > > > > > arch/i386/kernel/cpu/cpufreq/Kconfig: > > > config X86_P4_CLOCKMOD > > > tristate "Intel Pentium 4 clock modulation" > > > select CPU_FREQ_TABLE > > > help > > > > > > arch/x86_64/kernel/cpufreq/Kconfig: > > > config X86_P4_CLOCKMOD > > > tristate "Intel Pentium 4 clock modulation" > > > depends on EMBEDDED > > > help > > > > > > And if the option is mostly useless, what is it good for? > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > option (Speedstep/Powernow). The big misconception is that it > > somehow saves power & increases battery life. Not so. > > All it does is 'not do work so often'. The upside of this is > > that in some situations, we generate less heat this way. > > This is perplexing. Less heat equals less power usage according to the > laws of thermodynamics. you end up taking longer to do the same amount of work, so you end up using the same overall power. Dave ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 20:09 ` Dave Jones @ 2006-02-28 20:19 ` Dmitry Torokhov 2006-02-28 20:47 ` Matt Mackall 1 sibling, 0 replies; 63+ messages in thread From: Dmitry Torokhov @ 2006-02-28 20:19 UTC (permalink / raw) To: Dave Jones, Matt Mackall, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On 2/28/06, Dave Jones <davej@redhat.com> wrote: > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote: > > > > This is perplexing. Less heat equals less power usage according to the > > laws of thermodynamics. > > you end up taking longer to do the same amount of work, so you > end up using the same overall power. > I'd say that energy usage is the same _per unit of work_. But if you compare a box that is sitting idle 90% of the time at 0% throttling vs. a box that is sitting idle 80% of the time with 50% throttling and neither of these boxes support C2 you'll find that the second box uses less energy overall. -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 20:09 ` Dave Jones 2006-02-28 20:19 ` Dmitry Torokhov @ 2006-02-28 20:47 ` Matt Mackall 2006-02-28 20:57 ` Dominik Brodowski 1 sibling, 1 reply; 63+ messages in thread From: Matt Mackall @ 2006-02-28 20:47 UTC (permalink / raw) To: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote: > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote: > > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote: > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > > > > > > > config X86_P4_CLOCKMOD > > > > > > > depends on EMBEDDED > > > > > > > > > > > > This one is an x86_64 only issue, and yes, it's wrong. > > > > > > > > > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > > > > almost any energy savings it was "hidden" under embedded. > > > > > > > > But the EMBEDDED dependency is only on x86_64: > > > > > > > > arch/i386/kernel/cpu/cpufreq/Kconfig: > > > > config X86_P4_CLOCKMOD > > > > tristate "Intel Pentium 4 clock modulation" > > > > select CPU_FREQ_TABLE > > > > help > > > > > > > > arch/x86_64/kernel/cpufreq/Kconfig: > > > > config X86_P4_CLOCKMOD > > > > tristate "Intel Pentium 4 clock modulation" > > > > depends on EMBEDDED > > > > help > > > > > > > > And if the option is mostly useless, what is it good for? > > > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > > option (Speedstep/Powernow). The big misconception is that it > > > somehow saves power & increases battery life. Not so. > > > All it does is 'not do work so often'. The upside of this is > > > that in some situations, we generate less heat this way. > > > > This is perplexing. Less heat equals less power usage according to the > > laws of thermodynamics. > > you end up taking longer to do the same amount of work, so you > end up using the same overall power. Doesn't make sense. Power is energy consumption per unit time. Heat is energy dissipated per unit time (both are measured in watts). So if you're saying "we use the same amount of power", then conservation of energy implies "we generate the same amount of heat." If you're instead saying "we use the same amount of energy over a longer span of time", that means "we draw less power from the battery" which means "battery lasts longer". In short, power usage and heat production are _the same thing_. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 20:47 ` Matt Mackall @ 2006-02-28 20:57 ` Dominik Brodowski 2006-02-28 21:26 ` Matt Mackall 0 siblings, 1 reply; 63+ messages in thread From: Dominik Brodowski @ 2006-02-28 20:57 UTC (permalink / raw) To: Matt Mackall Cc: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Tue, Feb 28, 2006 at 02:47:20PM -0600, Matt Mackall wrote: > On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote: > > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote: > > > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote: > > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > > > > > > > > > config X86_P4_CLOCKMOD > > > > > > > > depends on EMBEDDED > > > > > > > > > > > > > > This one is an x86_64 only issue, and yes, it's wrong. > > > > > > > > > > > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > > > > > almost any energy savings it was "hidden" under embedded. > > > > > > > > > > But the EMBEDDED dependency is only on x86_64: > > > > > > > > > > arch/i386/kernel/cpu/cpufreq/Kconfig: > > > > > config X86_P4_CLOCKMOD > > > > > tristate "Intel Pentium 4 clock modulation" > > > > > select CPU_FREQ_TABLE > > > > > help > > > > > > > > > > arch/x86_64/kernel/cpufreq/Kconfig: > > > > > config X86_P4_CLOCKMOD > > > > > tristate "Intel Pentium 4 clock modulation" > > > > > depends on EMBEDDED > > > > > help > > > > > > > > > > And if the option is mostly useless, what is it good for? > > > > > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > > > option (Speedstep/Powernow). The big misconception is that it > > > > somehow saves power & increases battery life. Not so. > > > > All it does is 'not do work so often'. The upside of this is > > > > that in some situations, we generate less heat this way. > > > > > > This is perplexing. Less heat equals less power usage according to the > > > laws of thermodynamics. > > > > you end up taking longer to do the same amount of work, so you > > end up using the same overall power. > > Doesn't make sense. > > Power is energy consumption per unit time. Heat is energy dissipated > per unit time (both are measured in watts). So if you're saying "we > use the same amount of power", then conservation of energy implies "we > generate the same amount of heat." If you're instead saying "we use > the same amount of energy over a longer span of time", that means "we > draw less power from the battery" which means "battery lasts longer". So even if the battery lasts longer, you don't have anything of it, 'cause the CPU can even compute _less_ in this longer time-span. Remember that idling doesn't count... > In short, power usage and heat production are _the same thing_. Yes and no. The heat production is more levelled if you use throttling, so the temperature achieved is lesser, which might cause fans not having to start or air conditioning having less work to do. Dominik ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 20:57 ` Dominik Brodowski @ 2006-02-28 21:26 ` Matt Mackall 2006-02-28 21:34 ` Dominik Brodowski 0 siblings, 1 reply; 63+ messages in thread From: Matt Mackall @ 2006-02-28 21:26 UTC (permalink / raw) To: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Tue, Feb 28, 2006 at 09:57:58PM +0100, Dominik Brodowski wrote: > On Tue, Feb 28, 2006 at 02:47:20PM -0600, Matt Mackall wrote: > > On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote: > > > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote: > > > > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote: > > > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote: > > > > > > > > > > > > > > config X86_P4_CLOCKMOD > > > > > > > > > depends on EMBEDDED > > > > > > > > > > > > > > > > This one is an x86_64 only issue, and yes, it's wrong. > > > > > > > > > > > > > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > > > > > > almost any energy savings it was "hidden" under embedded. > > > > > > > > > > > > But the EMBEDDED dependency is only on x86_64: > > > > > > > > > > > > arch/i386/kernel/cpu/cpufreq/Kconfig: > > > > > > config X86_P4_CLOCKMOD > > > > > > tristate "Intel Pentium 4 clock modulation" > > > > > > select CPU_FREQ_TABLE > > > > > > help > > > > > > > > > > > > arch/x86_64/kernel/cpufreq/Kconfig: > > > > > > config X86_P4_CLOCKMOD > > > > > > tristate "Intel Pentium 4 clock modulation" > > > > > > depends on EMBEDDED > > > > > > help > > > > > > > > > > > > And if the option is mostly useless, what is it good for? > > > > > > > > > > It's sometimes useful in cases where the target CPU doesn't have any better > > > > > option (Speedstep/Powernow). The big misconception is that it > > > > > somehow saves power & increases battery life. Not so. > > > > > All it does is 'not do work so often'. The upside of this is > > > > > that in some situations, we generate less heat this way. > > > > > > > > This is perplexing. Less heat equals less power usage according to the > > > > laws of thermodynamics. > > > > > > you end up taking longer to do the same amount of work, so you > > > end up using the same overall power. > > > > Doesn't make sense. > > > > Power is energy consumption per unit time. Heat is energy dissipated > > per unit time (both are measured in watts). So if you're saying "we > > use the same amount of power", then conservation of energy implies "we > > generate the same amount of heat." If you're instead saying "we use > > the same amount of energy over a longer span of time", that means "we > > draw less power from the battery" which means "battery lasts longer". > > So even if the battery lasts longer, you don't have anything of it, 'cause > the CPU can even compute _less_ in this longer time-span. Remember that > idling doesn't count... Which is different from other power-saving modes how? If it means I can read my email longer on the plane, it's a power-saving mode. > > In short, power usage and heat production are _the same thing_. > > Yes and no. The heat production is more levelled if you use throttling, so > the temperature achieved is lesser, which might cause fans not having to > start or air conditioning having less work to do. The time scale for heat propagation is enough slower than throttling that I'd expect this difference to amount to approximately nil. It takes many seconds for heat to propagate from a core to a thermal sensor inside a laptop, and the intervening material (silicon, ceramic, plastic, aluminum, air) acts as a low-pass filter so usage spikes on sub-second scales are simply not visible. In other words, the temperature will be the same for the same energy consumption averaged over the time it takes for the heat to propagate. And the time for a usage spike to be visible to a server room air conditioner is probably closer to a ten minute time frame. -- Mathematics is the supreme nostalgia of our time. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 21:26 ` Matt Mackall @ 2006-02-28 21:34 ` Dominik Brodowski 2006-02-28 21:39 ` Dmitry Torokhov 0 siblings, 1 reply; 63+ messages in thread From: Dominik Brodowski @ 2006-02-28 21:34 UTC (permalink / raw) To: Matt Mackall Cc: Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote: > > So even if the battery lasts longer, you don't have anything of it, 'cause > > the CPU can even compute _less_ in this longer time-span. Remember that > > idling doesn't count... > > Which is different from other power-saving modes how? If it means I > can read my email longer on the plane, it's a power-saving mode. But you can't... [*] > > > In short, power usage and heat production are _the same thing_. > > > > Yes and no. The heat production is more levelled if you use throttling, so > > the temperature achieved is lesser, which might cause fans not having to > > start or air conditioning having less work to do. > > The time scale for heat propagation is enough slower than throttling > that I'd expect this difference to amount to approximately nil. For short-term load spikes, yes. If your server has a task which takes up one hour at full time, and the temp reaches 45° C then, but you have nothing else for it to do overnight, then it does might sense to throttle it to 50%, which will mean two hours, but only 40° C. Dominik [*] unless the idling algorithm is broken and does not enter C2-type idle states. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 21:34 ` Dominik Brodowski @ 2006-02-28 21:39 ` Dmitry Torokhov 2006-02-28 22:22 ` Andi Kleen 0 siblings, 1 reply; 63+ messages in thread From: Dmitry Torokhov @ 2006-02-28 21:39 UTC (permalink / raw) To: Matt Mackall, Dave Jones, Adrian Bunk, Dmitry Torokhov, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq, ak On 2/28/06, Dominik Brodowski <linux@dominikbrodowski.net> wrote: > On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote: > > > So even if the battery lasts longer, you don't have anything of it, 'cause > > > the CPU can even compute _less_ in this longer time-span. Remember that > > > idling doesn't count... > > > > Which is different from other power-saving modes how? If it means I > > can read my email longer on the plane, it's a power-saving mode. > > But you can't... [*] ... > [*] unless the idling algorithm is broken and does not enter C2-type idle > states. Or box does not support anything but C1. -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Status of X86_P4_CLOCKMOD? 2006-02-28 21:39 ` Dmitry Torokhov @ 2006-02-28 22:22 ` Andi Kleen 0 siblings, 0 replies; 63+ messages in thread From: Andi Kleen @ 2006-02-28 22:22 UTC (permalink / raw) To: dtor_core Cc: Matt Mackall, Dave Jones, Adrian Bunk, davej, Zwane Mwaikambo, Samuel Masham, Jan Engelhardt, linux-kernel, Andrew Morton, cpufreq On Tuesday 28 February 2006 22:39, Dmitry Torokhov wrote: > On 2/28/06, Dominik Brodowski <linux@dominikbrodowski.net> wrote: > > On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote: > > > > So even if the battery lasts longer, you don't have anything of it, 'cause > > > > the CPU can even compute _less_ in this longer time-span. Remember that > > > > idling doesn't count... > > > > > > Which is different from other power-saving modes how? If it means I > > > can read my email longer on the plane, it's a power-saving mode. > > > > But you can't... [*] > ... > > [*] unless the idling algorithm is broken and does not enter C2-type idle > > states. > > Or box does not support anything but C1. There are quite advanced forms of C1 around. And I would expect even old style dumb C1 to save more than throttling. -Andi ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 3:10 ` Adrian Bunk 2006-02-22 3:20 ` Dmitry Torokhov @ 2006-02-22 12:01 ` Herbert Poetzl 2006-02-22 12:15 ` Adrian Bunk 1 sibling, 1 reply; 63+ messages in thread From: Herbert Poetzl @ 2006-02-22 12:01 UTC (permalink / raw) To: Adrian Bunk Cc: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Wed, Feb 22, 2006 at 04:10:01AM +0100, Adrian Bunk wrote: > On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote: > > On Wed, Feb 22, 2006 at 03:31:21AM +0100, Adrian Bunk wrote: > > > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote: > > > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > > > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > > > > > > > > > > > Hi Adrian, > > > > > > > > > > Hi Samuel, > > > > > > > > > > > > And I've already given numbers why CONFIG_EMBEDDED=y and > > > > > > > CONFIG_MODULES=y at the same time is insane. > > > > > > > > > > > > >From your numbers this sounds true ... but actually you might want the > > > > > > modules to delay the init of the various hardware bits... > > > > > > > > > > > > Sometime boot-time is king and you just try and get back as much of > > > > > > the size costs as it takes... > > > > > > > > > > this is irrelevant since CONFIG_INPUT alone does not init any hardware. > > > > > > > > > > > I think for EMBEDDED and MODULES is actually a very common case ... if > > > > > > somewhat odd. > > > > > > > > > > You are misunderstanding EMBEDDED. > > > > > > > > well, I suggested the following (or a similar) > > > > change some time ago (unfortunately I could not > > > > find it in the lkml archives, so it might have > > > > been lost) > > > > > > > > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt > > > > > > That's not a good solution since EMBEDDED is really only about > > > additional space savings - even if you are an "expert", there's no > > > reason to enable EMBEDDED when building a kernel for systems > > > with > 50 MB RAM. > > > > well, not sure everybody kows that ... > > > > config X86_P4_CLOCKMOD > > depends on EMBEDDED > > This one is an x86_64 only issue, and yes, it's wrong. > > > config VT_CONSOLE > > bool "Support for console on virtual terminal" if EMBEDDED > > Looks OK. > > > config VGA_CONSOLE > > bool "VGA text console" if EMBEDDED > > Looks OK. > > > config DNOTIFY > > bool "Dnotify support" if EMBEDDED > > Looks OK. > > > config DEBUG_BUGVERBOSE > > bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED > > Looks OK. > > > but, the patch was just considered a starting point > > so that folks would know _what_ EMBEDDED is currently > > used for ... > > Except for the X86_P4_CLOCKMOD case, all of your examples are correct > usages of EMBEDDED. ahem, well, then I'm definitely doing something wrong when I disable the VGA console on my 2GB servers, as "there's no reason to enable EMBEDDED when building a kernel for systems with > 50 MB RAM" sorry, I kind of disagree here, this might be useful for embedded systems, but it is definitely useful for other systems as well ... at least I do not like the 'assumption' that every system with >50MB has to have a VGA console ... I agree that the 0815 distro will not need this and it can be hidden behind some option ... best, Herbert > > > The better solution is IMHO an additional option: > > > http://lkml.org/lkml/2006/2/7/93 > > > http://lkml.org/lkml/2006/2/7/139 > > > > whatever, just get rid of the CONFIG_EMBEDDED everybody > > get's wrong and nobody really understands ... > > No, the EMBEDDED semantics shouldn't be changed and most people get it > right. > > Naming it EXPERT as you suggested would make it even worse. We could name it > SHOW_OPTIONS_FOR_ADDITIONAL_SPACE_SAVINGS_IF_YOU_REALLY_KNOW_WHAT_YOU_ARE_DOING, > but unless someone comes up with a name that is both short and > significantely better than EMBEDDED I don't see a reason for changing it. > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 12:01 ` [2.6 patch] make INPUT a bool Herbert Poetzl @ 2006-02-22 12:15 ` Adrian Bunk 2006-02-22 18:09 ` Herbert Poetzl 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-22 12:15 UTC (permalink / raw) To: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Wed, Feb 22, 2006 at 01:01:21PM +0100, Herbert Poetzl wrote: > On Wed, Feb 22, 2006 at 04:10:01AM +0100, Adrian Bunk wrote: >... > > Except for the X86_P4_CLOCKMOD case, all of your examples are correct > > usages of EMBEDDED. > > ahem, well, then I'm definitely doing something > wrong when I disable the VGA console on my 2GB > servers, as "there's no reason to enable EMBEDDED > when building a kernel for systems with > 50 MB RAM" > > sorry, I kind of disagree here, this might be useful > for embedded systems, but it is definitely useful > for other systems as well ... at least I do not like > the 'assumption' that every system with >50MB has > to have a VGA console ... > > I agree that the 0815 distro will not need this and > it can be hidden behind some option ... It's not assumed that every system with > 50 MB has a VGA console. These are options where accidentially disabling only causes problems for the majority of users. You can enable EMBEDDED on your 2 GB servers if you really want to save a few bytes in the kernel, but OTOH I doubt there is much practival value in reducing the kernel for a system with 2 GB RAM by a few kB. > best, > Herbert >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 12:15 ` Adrian Bunk @ 2006-02-22 18:09 ` Herbert Poetzl 0 siblings, 0 replies; 63+ messages in thread From: Herbert Poetzl @ 2006-02-22 18:09 UTC (permalink / raw) To: Adrian Bunk Cc: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, linux-kernel, linux-input, Andrew Morton On Wed, Feb 22, 2006 at 01:15:42PM +0100, Adrian Bunk wrote: > On Wed, Feb 22, 2006 at 01:01:21PM +0100, Herbert Poetzl wrote: > > On Wed, Feb 22, 2006 at 04:10:01AM +0100, Adrian Bunk wrote: > >... > > > Except for the X86_P4_CLOCKMOD case, all of your examples are correct > > > usages of EMBEDDED. > > > > ahem, well, then I'm definitely doing something > > wrong when I disable the VGA console on my 2GB > > servers, as "there's no reason to enable EMBEDDED > > when building a kernel for systems with > 50 MB RAM" > > > > sorry, I kind of disagree here, this might be useful > > for embedded systems, but it is definitely useful > > for other systems as well ... at least I do not like > > the 'assumption' that every system with >50MB has > > to have a VGA console ... > > > > I agree that the 0815 distro will not need this and > > it can be hidden behind some option ... > > It's not assumed that every system with > 50 MB has a VGA console. > > These are options where accidentially disabling only causes problems > for the majority of users. > > You can enable EMBEDDED on your 2 GB servers if you really want > to save a few bytes in the kernel, but OTOH I doubt there is much > practival value in reducing the kernel for a system with 2 GB RAM by a > few kB. it is not the size I care about, it is the missing/disabled vga hardware (and serial console) that I care about, but what the hell, you consider it EMBEDDED and I don't. period. nevertheless folks put all kind of stuff under EMBEDDED because they _think_ it actually means _SPECIALIST_ or _EXPERT_ and just is bad namimg ... that's something which IMHO should be clarified, and if it is just by adding another Kconfig option which does that > > best, > > Herbert > >... > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-22 2:31 ` Adrian Bunk 2006-02-22 2:44 ` Herbert Poetzl @ 2006-02-25 11:58 ` Geert Uytterhoeven 2006-02-25 12:46 ` Adrian Bunk 1 sibling, 1 reply; 63+ messages in thread From: Geert Uytterhoeven @ 2006-02-25 11:58 UTC (permalink / raw) To: Adrian Bunk Cc: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On Wed, 22 Feb 2006, Adrian Bunk wrote: > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote: > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > That's not a good solution since EMBEDDED is really only about > additional space savings - even if you are an "expert", there's no > reason to enable EMBEDDED when building a kernel for systems > with > 50 MB RAM. and On Fri, 17 Feb 2006, Adrian Bunk wrote: > And I've already given numbers why CONFIG_EMBEDDED=y and > CONFIG_MODULES=y at the same time is insane. But if my m68k box has less than 47.68 MiB RAM, I may want CONFIG_EMBEDDED=y, and I like to have CONFIG_MODULES=y... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 11:58 ` Geert Uytterhoeven @ 2006-02-25 12:46 ` Adrian Bunk 2006-02-25 14:22 ` Jan Engelhardt 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-25 12:46 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Samuel Masham, Jan Engelhardt, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 12:58:01PM +0100, Geert Uytterhoeven wrote: > On Wed, 22 Feb 2006, Adrian Bunk wrote: > > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote: > > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote: > > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote: > > That's not a good solution since EMBEDDED is really only about > > additional space savings - even if you are an "expert", there's no > > reason to enable EMBEDDED when building a kernel for systems > > with > 50 MB RAM. > > and > > On Fri, 17 Feb 2006, Adrian Bunk wrote: > > And I've already given numbers why CONFIG_EMBEDDED=y and > > CONFIG_MODULES=y at the same time is insane. > > But if my m68k box has less than 47.68 MiB RAM, I may want CONFIG_EMBEDDED=y, > and I like to have CONFIG_MODULES=y... My 50 MB number was much too high (I didn't want to think where exactly to set the borderline). My point is that if you are in an environment that is that space limited that you want to see options that allow e.g. not building futexes, module support with an impact of approx. 10% on code size would be one of the first things you should disable. > Gr{oetje,eeting}s, > Geert cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 12:46 ` Adrian Bunk @ 2006-02-25 14:22 ` Jan Engelhardt 2006-02-25 14:50 ` Adrian Bunk 2006-02-25 14:57 ` Jesper Juhl 0 siblings, 2 replies; 63+ messages in thread From: Jan Engelhardt @ 2006-02-25 14:22 UTC (permalink / raw) To: Adrian Bunk Cc: Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton > >My 50 MB number was much too high (I didn't want to think where exactly >to set the borderline). > >My point is that if you are in an environment that is that space limited >that you want to see options that allow e.g. not building futexes, >module support with an impact of approx. 10% on code size would be one >of the first things you should disable. > You said that INPUT was not a driver, right. But without it, a keyboard won't work, will it? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 14:22 ` Jan Engelhardt @ 2006-02-25 14:50 ` Adrian Bunk 2006-02-25 15:29 ` Jan Engelhardt 2006-02-25 14:57 ` Jesper Juhl 1 sibling, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-25 14:50 UTC (permalink / raw) To: Jan Engelhardt Cc: Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 03:22:04PM +0100, Jan Engelhardt wrote: > > > >My 50 MB number was much too high (I didn't want to think where exactly > >to set the borderline). > > > >My point is that if you are in an environment that is that space limited > >that you want to see options that allow e.g. not building futexes, > >module support with an impact of approx. 10% on code size would be one > >of the first things you should disable. > > > > You said that INPUT was not a driver, right. But without it, a keyboard > won't work, will it? Yes, you do need INPUT for a keyboard. No, INPUT alone does not support any hardware - that's the job of the drivers depending on INPUT. No, I don't understand what your question wants to achieve. > Jan Engelhardt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 14:50 ` Adrian Bunk @ 2006-02-25 15:29 ` Jan Engelhardt 2006-02-25 15:40 ` Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Jan Engelhardt @ 2006-02-25 15:29 UTC (permalink / raw) To: Adrian Bunk Cc: Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton >> >> You said that INPUT was not a driver, right. But without it, a keyboard >> won't work, will it? > >Yes, you do need INPUT for a keyboard. > >No, INPUT alone does not support any hardware - that's the job of the >drivers depending on INPUT. > >No, I don't understand what your question wants to achieve. > Let's look at another subsystem: "Yes, you do need SND for a soundcard." "No, SND alone does not support any hardware - that's the job of the drivers depending on SND." Should SND also be made a bool like INPUT? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 15:29 ` Jan Engelhardt @ 2006-02-25 15:40 ` Adrian Bunk 2006-02-25 22:01 ` Jan Engelhardt 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-25 15:40 UTC (permalink / raw) To: Jan Engelhardt Cc: Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 04:29:16PM +0100, Jan Engelhardt wrote: > >> > >> You said that INPUT was not a driver, right. But without it, a keyboard > >> won't work, will it? > > > >Yes, you do need INPUT for a keyboard. > > > >No, INPUT alone does not support any hardware - that's the job of the > >drivers depending on INPUT. > > > >No, I don't understand what your question wants to achieve. > > > > Let's look at another subsystem: > > "Yes, you do need SND for a soundcard." > > "No, SND alone does not support any hardware - that's the job of the drivers > depending on SND." > > Should SND also be made a bool like INPUT? No, SND=m is also possible in the EMBEDDED=n case. > Jan Engelhardt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 15:40 ` Adrian Bunk @ 2006-02-25 22:01 ` Jan Engelhardt 2006-02-25 22:07 ` Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Jan Engelhardt @ 2006-02-25 22:01 UTC (permalink / raw) To: Adrian Bunk Cc: Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton >> >> You said that INPUT was not a driver, right. But without it, a keyboard >> >> won't work, will it? >> > >> >Yes, you do need INPUT for a keyboard. >> >No, INPUT alone does not support any hardware - that's the job of the >> >drivers depending on INPUT. >> >No, I don't understand what your question wants to achieve. >> >> Let's look at another subsystem: >> "Yes, you do need SND for a soundcard." >> "No, SND alone does not support any hardware - that's the job of the drivers >> depending on SND." >> Should SND also be made a bool like INPUT? > >No, SND=m is also possible in the EMBEDDED=n case. > This example was to show that INPUT should not be y-only. Except if you plan to make SND y-only too. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 22:01 ` Jan Engelhardt @ 2006-02-25 22:07 ` Adrian Bunk 2006-02-25 22:23 ` Dmitry Torokhov 2006-02-27 12:59 ` Vojtech Pavlik 0 siblings, 2 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-25 22:07 UTC (permalink / raw) To: Jan Engelhardt Cc: Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 11:01:03PM +0100, Jan Engelhardt wrote: > >> >> You said that INPUT was not a driver, right. But without it, a keyboard > >> >> won't work, will it? > >> > > >> >Yes, you do need INPUT for a keyboard. > >> >No, INPUT alone does not support any hardware - that's the job of the > >> >drivers depending on INPUT. > >> >No, I don't understand what your question wants to achieve. > >> > >> Let's look at another subsystem: > >> "Yes, you do need SND for a soundcard." > >> "No, SND alone does not support any hardware - that's the job of the drivers > >> depending on SND." > >> Should SND also be made a bool like INPUT? > > > >No, SND=m is also possible in the EMBEDDED=n case. > > > This example was to show that INPUT should not be y-only. Except if you plan to > make SND y-only too. Please try to understand the following: - INPUT=m is already only available if EMBEDDED=y - as I did already explain, EMBEDDED=y and MODULES=y at the same time doesn't make much sense As I already said, SND=m is completely different since it is also available in the (common) EMBEDDED=n case. > Jan Engelhardt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 22:07 ` Adrian Bunk @ 2006-02-25 22:23 ` Dmitry Torokhov 2006-02-26 18:13 ` Adrian Bunk 2006-02-27 7:11 ` Vojtech Pavlik 2006-02-27 12:59 ` Vojtech Pavlik 1 sibling, 2 replies; 63+ messages in thread From: Dmitry Torokhov @ 2006-02-25 22:23 UTC (permalink / raw) To: Adrian Bunk Cc: Jan Engelhardt, Geert Uytterhoeven, Samuel Masham, Linux Kernel Development, linux-input, Andrew Morton On Saturday 25 February 2006 17:07, Adrian Bunk wrote: > On Sat, Feb 25, 2006 at 11:01:03PM +0100, Jan Engelhardt wrote: > > >> >> You said that INPUT was not a driver, right. But without it, a keyboard > > >> >> won't work, will it? > > >> > > > >> >Yes, you do need INPUT for a keyboard. > > >> >No, INPUT alone does not support any hardware - that's the job of the > > >> >drivers depending on INPUT. > > >> >No, I don't understand what your question wants to achieve. > > >> > > >> Let's look at another subsystem: > > >> "Yes, you do need SND for a soundcard." > > >> "No, SND alone does not support any hardware - that's the job of the drivers > > >> depending on SND." > > >> Should SND also be made a bool like INPUT? > > > > > >No, SND=m is also possible in the EMBEDDED=n case. > > > > > This example was to show that INPUT should not be y-only. Except if you plan to > > make SND y-only too. > > > Please try to understand the following: > - INPUT=m is already only available if EMBEDDED=y Adrian, There are requests to move it out of EMBEDDED because sometimes you just don't need input layer at all. Dave Jones mentioned that he feels silly enabling EMBEDDED on iSeries... I am thinking about changing it to "EMBEDDED || !X86_PC" to safe-guard the most common platform from accidenially disabling it. I am still not convinced whether INPUT=m makes sence, especially if we make ACPI use input layer... Jan's example about input device with hot-pluggable keyboard is a bit of a stretch. -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 22:23 ` Dmitry Torokhov @ 2006-02-26 18:13 ` Adrian Bunk 2006-02-27 7:11 ` Vojtech Pavlik 1 sibling, 0 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-26 18:13 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jan Engelhardt, Geert Uytterhoeven, Samuel Masham, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 05:23:52PM -0500, Dmitry Torokhov wrote: > > Adrian, > > There are requests to move it out of EMBEDDED because sometimes you > just don't need input layer at all. Dave Jones mentioned that he > feels silly enabling EMBEDDED on iSeries... I am thinking about > changing it to "EMBEDDED || !X86_PC" to safe-guard the most common > platform from accidenially disabling it. Sounds reasonable. > I am still not convinced whether INPUT=m makes sence, especially if > we make ACPI use input layer... Jan's example about input device with > hot-pluggable keyboard is a bit of a stretch. Agreed. > Dmitry cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 22:23 ` Dmitry Torokhov 2006-02-26 18:13 ` Adrian Bunk @ 2006-02-27 7:11 ` Vojtech Pavlik 1 sibling, 0 replies; 63+ messages in thread From: Vojtech Pavlik @ 2006-02-27 7:11 UTC (permalink / raw) To: Dmitry Torokhov Cc: Adrian Bunk, Jan Engelhardt, Geert Uytterhoeven, Samuel Masham, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 05:23:52PM -0500, Dmitry Torokhov wrote: > Adrian, > > There are requests to move it out of EMBEDDED because sometimes you > just don't need input layer at all. Dave Jones mentioned that he > feels silly enabling EMBEDDED on iSeries... I am thinking about > changing it to "EMBEDDED || !X86_PC" to safe-guard the most common > platform from accidenially disabling it. > > I am still not convinced whether INPUT=m makes sence, especially if > we make ACPI use input layer... Jan's example about input device with > hot-pluggable keyboard is a bit of a stretch. The possibility to keep INPUT=m makes a big sense in that it keeps the interfaces to the rest of the kernel clean. No direct linking, no callbacks into inner functions from elsewhere, etc. Nicely isolated. Even with ACPI, the part that will use input will usually be modular, too. The only big user of INPUT, which can't be modular at the time is CONFIG_VT. And this, I believe, is a bug. -- Vojtech Pavlik Director SuSE Labs ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 22:07 ` Adrian Bunk 2006-02-25 22:23 ` Dmitry Torokhov @ 2006-02-27 12:59 ` Vojtech Pavlik 1 sibling, 0 replies; 63+ messages in thread From: Vojtech Pavlik @ 2006-02-27 12:59 UTC (permalink / raw) To: Adrian Bunk Cc: Jan Engelhardt, Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On Sat, Feb 25, 2006 at 11:07:38PM +0100, Adrian Bunk wrote: > On Sat, Feb 25, 2006 at 11:01:03PM +0100, Jan Engelhardt wrote: > > >> >> You said that INPUT was not a driver, right. But without it, a keyboard > > >> >> won't work, will it? > > >> > > > >> >Yes, you do need INPUT for a keyboard. > > >> >No, INPUT alone does not support any hardware - that's the job of the > > >> >drivers depending on INPUT. > > >> >No, I don't understand what your question wants to achieve. > > >> > > >> Let's look at another subsystem: > > >> "Yes, you do need SND for a soundcard." > > >> "No, SND alone does not support any hardware - that's the job of the drivers > > >> depending on SND." > > >> Should SND also be made a bool like INPUT? > > > > > >No, SND=m is also possible in the EMBEDDED=n case. > > > > > This example was to show that INPUT should not be y-only. Except if you plan to > > make SND y-only too. > > > Please try to understand the following: > - INPUT=m is already only available if EMBEDDED=y That is because too many people were making the mistake of saying 'N' to INPUT. EMBEDDED here was really chosen while meaning EXPERT. This has nothing to do with the kernel image size - the size of input.c is pretty minimal anyway. > - as I did already explain, EMBEDDED=y and MODULES=y at the same > time doesn't make much sense It doesn't. But in the same way making INPUT depend on EMBEDDED doesn't make sense if you intend EMBEDDED to truly mean what it says. > As I already said, SND=m is completely different since it is also > available in the (common) EMBEDDED=n case. It's not. Input, like sound, scsi, usb, firewire .... is just another subsystem in the kernel. The kernel can live without it, and it used to work just fine when all modular, including autoloading. -- Vojtech Pavlik Director SuSE Labs ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-25 14:22 ` Jan Engelhardt 2006-02-25 14:50 ` Adrian Bunk @ 2006-02-25 14:57 ` Jesper Juhl 1 sibling, 0 replies; 63+ messages in thread From: Jesper Juhl @ 2006-02-25 14:57 UTC (permalink / raw) To: Jan Engelhardt Cc: Adrian Bunk, Geert Uytterhoeven, Samuel Masham, Dmitry Torokhov, Linux Kernel Development, linux-input, Andrew Morton On 2/25/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >My 50 MB number was much too high (I didn't want to think where exactly > >to set the borderline). > > > >My point is that if you are in an environment that is that space limited > >that you want to see options that allow e.g. not building futexes, > >module support with an impact of approx. 10% on code size would be one > >of the first things you should disable. > > > > You said that INPUT was not a driver, right. But without it, a keyboard > won't work, will it? > No, it won't, so if you want to use a keyboard you build INPUT into the kernel. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-14 15:22 [2.6 patch] make INPUT a bool Adrian Bunk 2006-02-14 18:14 ` Jan Engelhardt @ 2006-02-15 6:20 ` Dmitry Torokhov 2006-02-16 23:22 ` Adrian Bunk 1 sibling, 1 reply; 63+ messages in thread From: Dmitry Torokhov @ 2006-02-15 6:20 UTC (permalink / raw) To: Adrian Bunk; +Cc: linux-kernel, linux-input On Tuesday 14 February 2006 10:22, Adrian Bunk wrote: > Make INPUT a bool. > > INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't > make that much sense to make it modular. > Adrian, We also need to get rid of input_register_device pinning input module and input_dev release function decrementing module's refcount. Thanks! -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* [2.6 patch] make INPUT a bool 2006-02-15 6:20 ` Dmitry Torokhov @ 2006-02-16 23:22 ` Adrian Bunk 2006-02-17 1:47 ` Dmitry Torokhov 0 siblings, 1 reply; 63+ messages in thread From: Adrian Bunk @ 2006-02-16 23:22 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-kernel, linux-input On Wed, Feb 15, 2006 at 01:20:58AM -0500, Dmitry Torokhov wrote: > On Tuesday 14 February 2006 10:22, Adrian Bunk wrote: > > Make INPUT a bool. > > > > INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't > > make that much sense to make it modular. > > > > Adrian, > > We also need to get rid of input_register_device pinning input module > and input_dev release function decrementing module's refcount. Is the patch below OK? > Thanks! > Dmitry cu Adrian <-- snip --> Make INPUT a bool. INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't make that much sense to make it modular. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- drivers/input/Kconfig | 2 +- drivers/input/input.c | 21 --------------------- 2 files changed, 1 insertion(+), 22 deletions(-) --- linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig.old 2006-02-03 22:42:18.000000000 +0100 +++ linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig 2006-02-03 22:42:29.000000000 +0100 @@ -5,7 +5,7 @@ menu "Input device support" config INPUT - tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED + bool "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED default y ---help--- Say Y here if you have any input device (mouse, keyboard, tablet, --- linux-2.6.16-rc3-mm1-full/drivers/input/input.c.old 2006-02-16 23:59:47.000000000 +0100 +++ linux-2.6.16-rc3-mm1-full/drivers/input/input.c 2006-02-17 00:06:06.000000000 +0100 @@ -23,10 +23,6 @@ #include <linux/device.h> #include <linux/mutex.h> -MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>"); -MODULE_DESCRIPTION("Input core"); -MODULE_LICENSE("GPL"); - EXPORT_SYMBOL(input_allocate_device); EXPORT_SYMBOL(input_register_device); EXPORT_SYMBOL(input_unregister_device); @@ -470,13 +466,10 @@ if (!proc_bus_input_dir) return -ENOMEM; - proc_bus_input_dir->owner = THIS_MODULE; - entry = create_proc_read_entry("devices", 0, proc_bus_input_dir, input_devices_read, NULL); if (!entry) goto fail1; - entry->owner = THIS_MODULE; input_fileops = *entry->proc_fops; input_fileops.poll = input_devices_poll; entry->proc_fops = &input_fileops; @@ -485,8 +478,6 @@ if (!entry) goto fail2; - entry->owner = THIS_MODULE; - return 0; fail2: remove_proc_entry("devices", proc_bus_input_dir); @@ -662,7 +653,6 @@ struct input_dev *dev = to_input_dev(class_dev); kfree(dev); - module_put(THIS_MODULE); } /* @@ -830,8 +820,6 @@ if (error) goto fail3; - __module_get(THIS_MODULE); - path = kobject_get_path(&dev->cdev.kobj, GFP_KERNEL); printk(KERN_INFO "input: %s as %s\n", dev->name ? dev->name : "Unspecified device", path ? path : "N/A"); @@ -953,7 +941,6 @@ } static struct file_operations input_fops = { - .owner = THIS_MODULE, .open = input_open_file, }; @@ -984,12 +971,4 @@ return err; } -static void __exit input_exit(void) -{ - input_proc_exit(); - unregister_chrdev(INPUT_MAJOR, "input"); - class_unregister(&input_class); -} - subsys_initcall(input_init); -module_exit(input_exit); ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [2.6 patch] make INPUT a bool 2006-02-16 23:22 ` Adrian Bunk @ 2006-02-17 1:47 ` Dmitry Torokhov 0 siblings, 0 replies; 63+ messages in thread From: Dmitry Torokhov @ 2006-02-17 1:47 UTC (permalink / raw) To: Adrian Bunk; +Cc: linux-kernel, linux-input On 2/16/06, Adrian Bunk <bunk@stusta.de> wrote: > On Wed, Feb 15, 2006 at 01:20:58AM -0500, Dmitry Torokhov wrote: > > On Tuesday 14 February 2006 10:22, Adrian Bunk wrote: > > > Make INPUT a bool. > > > > > > INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't > > > make that much sense to make it modular. > > > > > > > Adrian, > > > > We also need to get rid of input_register_device pinning input module > > and input_dev release function decrementing module's refcount. > > Is the patch below OK? > Looks great! Thank you, Adrian. -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH] Export symbols so CONFIG_INPUT works as a module @ 2006-01-24 18:19 Martin Michlmayr 2006-01-24 23:08 ` Dmitry Torokhov 0 siblings, 1 reply; 63+ messages in thread From: Martin Michlmayr @ 2006-01-24 18:19 UTC (permalink / raw) To: linux-kernel Currently, modular input support fails to load with the following error: qube:# modprobe input input: Unknown symbol kobject_get_path input: Unknown symbol add_input_randomness In the short run, this can be solved by exporting these two symbols. There have been discussions about fixing this in a different manner, see http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/1068.html Since this was in the days of 2.6.12-rc4 and modular input support is still broken, I suggest these symbols to be exported for now. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> --- drivers/char/random.c | 2 ++ lib/kobject.c | 1 + 2 files changed, 3 insertions(+) --- a/drivers/char/random.c 2006-01-24 18:11:26.000000000 +0000 +++ b/drivers/char/random.c 2006-01-24 18:11:57.000000000 +0000 @@ -647,6 +647,8 @@ (type << 4) ^ code ^ (code >> 4) ^ value); } +EXPORT_SYMBOL(add_input_randomness); + void add_interrupt_randomness(int irq) { if (irq >= NR_IRQS || irq_timer_state[irq] == 0) --- a/lib/kobject.c 2006-01-24 18:12:15.000000000 +0000 +++ b/lib/kobject.c 2006-01-24 18:12:43.000000000 +0000 @@ -527,6 +527,7 @@ EXPORT_SYMBOL(kobject_init); EXPORT_SYMBOL(kobject_register); EXPORT_SYMBOL(kobject_unregister); +EXPORT_SYMBOL(kobject_get_path); EXPORT_SYMBOL(kobject_get); EXPORT_SYMBOL(kobject_put); EXPORT_SYMBOL(kobject_add); -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Export symbols so CONFIG_INPUT works as a module @ 2006-01-24 23:08 ` Dmitry Torokhov 2006-01-24 23:14 ` Martin Michlmayr 0 siblings, 1 reply; 63+ messages in thread From: Dmitry Torokhov @ 2006-01-24 23:08 UTC (permalink / raw) To: Al Viro; +Cc: Dave Jones, Martin Michlmayr, linux-kernel On 1/24/06, Al Viro <viro@ftp.linux.org.uk> wrote: > On Tue, Jan 24, 2006 at 01:34:32PM -0500, Dave Jones wrote: > > On Tue, Jan 24, 2006 at 06:19:45PM +0000, Martin Michlmayr wrote: > > > Currently, modular input support fails to load with the following error: > > > > > > qube:# modprobe input > > > input: Unknown symbol kobject_get_path > > > input: Unknown symbol add_input_randomness > > > > > > In the short run, this can be solved by exporting these two symbols. > > > There have been discussions about fixing this in a different manner, > > > see http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/1068.html > > > Since this was in the days of 2.6.12-rc4 and modular input support is > > > still broken, I suggest these symbols to be exported for now. > > > > Is there actually any practical reason why you would want to > > make the input layer modular ? > > More interesting question: is pis^H^H^Hsysfs interaction in there safe for > modular code? The core should be safe, at least I was trying to make it this way, so if you see something wrong - shout. Locking is another question though... -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Export symbols so CONFIG_INPUT works as a module 2006-01-24 23:08 ` Dmitry Torokhov @ 2006-01-24 23:14 ` Martin Michlmayr 2006-01-25 5:04 ` Dmitry Torokhov 0 siblings, 1 reply; 63+ messages in thread From: Martin Michlmayr @ 2006-01-24 23:14 UTC (permalink / raw) To: dtor_core; +Cc: Al Viro, Dave Jones, linux-kernel * Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-01-24 18:08]: > > More interesting question: is pis^H^H^Hsysfs interaction in there safe for > > modular code? > > The core should be safe, at least I was trying to make it this way, so > if you see something wrong - shout. Locking is another question > though... So do you want an updated patch using _GPL to export the symbols or to change CONFIG_INPUT to boolean? -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] Export symbols so CONFIG_INPUT works as a module 2006-01-24 23:14 ` Martin Michlmayr @ 2006-01-25 5:04 ` Dmitry Torokhov 2006-02-03 22:36 ` [2.6 patch] make INPUT a bool Adrian Bunk 0 siblings, 1 reply; 63+ messages in thread From: Dmitry Torokhov @ 2006-01-25 5:04 UTC (permalink / raw) To: Martin Michlmayr; +Cc: Al Viro, Dave Jones, linux-kernel, Vojtech Pavlik On Tuesday 24 January 2006 18:14, Martin Michlmayr wrote: > * Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-01-24 18:08]: > > > More interesting question: is pis^H^H^Hsysfs interaction in there safe for > > > modular code? > > > > The core should be safe, at least I was trying to make it this way, so > > if you see something wrong - shout. Locking is another question > > though... > > So do you want an updated patch using _GPL to export the symbols or to > change CONFIG_INPUT to boolean? I guess having input core as a module does not make much sense, so we should change CONFIG_INPUT to be boolean _and_ clean up the core code removing module unloading support. -- Dmitry ^ permalink raw reply [flat|nested] 63+ messages in thread
* [2.6 patch] make INPUT a bool 2006-01-25 5:04 ` Dmitry Torokhov @ 2006-02-03 22:36 ` Adrian Bunk 0 siblings, 0 replies; 63+ messages in thread From: Adrian Bunk @ 2006-02-03 22:36 UTC (permalink / raw) To: Dmitry Torokhov Cc: Martin Michlmayr, Al Viro, Dave Jones, linux-kernel, Vojtech Pavlik On Wed, Jan 25, 2006 at 12:04:06AM -0500, Dmitry Torokhov wrote: > On Tuesday 24 January 2006 18:14, Martin Michlmayr wrote: > > * Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-01-24 18:08]: > > > > More interesting question: is pis^H^H^Hsysfs interaction in there safe for > > > > modular code? > > > > > > The core should be safe, at least I was trying to make it this way, so > > > if you see something wrong - shout. Locking is another question > > > though... > > > > So do you want an updated patch using _GPL to export the symbols or to > > change CONFIG_INPUT to boolean? > > I guess having input core as a module does not make much sense, so > we should change CONFIG_INPUT to be boolean _and_ clean up the core > code removing module unloading support. Is the patch below what you were thinking of? > Dmitry cu Adrian <-- snip --> Make INPUT a bool. INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't make that much sense to make it modular. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- drivers/input/Kconfig | 2 +- drivers/input/input.c | 8 -------- 2 files changed, 1 insertion(+), 9 deletions(-) --- linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig.old 2006-02-03 22:42:18.000000000 +0100 +++ linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig 2006-02-03 22:42:29.000000000 +0100 @@ -5,7 +5,7 @@ menu "Input device support" config INPUT - tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED + bool "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED default y ---help--- Say Y here if you have any input device (mouse, keyboard, tablet, --- linux-2.6.16-rc1-mm5-full/drivers/input/input.c.old 2006-02-03 22:42:41.000000000 +0100 +++ linux-2.6.16-rc1-mm5-full/drivers/input/input.c 2006-02-03 22:47:44.000000000 +0100 @@ -984,12 +984,4 @@ return err; } -static void __exit input_exit(void) -{ - input_proc_exit(); - unregister_chrdev(INPUT_MAJOR, "input"); - class_unregister(&input_class); -} - subsys_initcall(input_init); -module_exit(input_exit); ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2006-02-28 22:22 UTC | newest] Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-14 15:22 [2.6 patch] make INPUT a bool Adrian Bunk 2006-02-14 18:14 ` Jan Engelhardt 2006-02-14 18:22 ` Adrian Bunk 2006-02-14 23:47 ` Adrian Bunk 2006-02-17 15:56 ` Jan Engelhardt 2006-02-17 16:38 ` Adrian Bunk 2006-02-20 3:33 ` Samuel Masham 2006-02-20 13:28 ` Adrian Bunk 2006-02-22 1:34 ` Herbert Poetzl 2006-02-22 2:31 ` Adrian Bunk 2006-02-22 2:44 ` Herbert Poetzl 2006-02-22 3:10 ` Adrian Bunk 2006-02-22 3:20 ` Dmitry Torokhov 2006-02-23 19:59 ` Status of X86_P4_CLOCKMOD? Adrian Bunk 2006-02-23 20:41 ` Dave Jones 2006-02-23 23:15 ` Andi Kleen 2006-02-23 23:33 ` Adrian Bunk 2006-02-23 23:55 ` Andi Kleen 2006-02-24 2:39 ` Adrian Bunk 2006-02-24 2:42 ` Andi Kleen 2006-02-24 17:33 ` Adrian Bunk 2006-02-25 1:57 ` Johannes Stezenbach 2006-02-25 4:24 ` Dave Jones 2006-02-25 12:53 ` Johannes Stezenbach 2006-02-27 21:17 ` Wes Felter 2006-02-25 4:27 ` Andi Kleen 2006-02-25 12:53 ` Adrian Bunk 2006-02-25 13:28 ` Dominik Brodowski 2006-02-26 11:12 ` Pavel Machek 2006-02-26 20:39 ` Johannes Stezenbach 2006-02-26 20:55 ` Dominik Brodowski 2006-02-26 23:37 ` Johannes Stezenbach 2006-02-25 13:36 ` Andi Kleen 2006-02-25 13:05 ` Johannes Stezenbach 2006-02-28 19:46 ` Matt Mackall 2006-02-28 20:09 ` Dave Jones 2006-02-28 20:19 ` Dmitry Torokhov 2006-02-28 20:47 ` Matt Mackall 2006-02-28 20:57 ` Dominik Brodowski 2006-02-28 21:26 ` Matt Mackall 2006-02-28 21:34 ` Dominik Brodowski 2006-02-28 21:39 ` Dmitry Torokhov 2006-02-28 22:22 ` Andi Kleen 2006-02-22 12:01 ` [2.6 patch] make INPUT a bool Herbert Poetzl 2006-02-22 12:15 ` Adrian Bunk 2006-02-22 18:09 ` Herbert Poetzl 2006-02-25 11:58 ` Geert Uytterhoeven 2006-02-25 12:46 ` Adrian Bunk 2006-02-25 14:22 ` Jan Engelhardt 2006-02-25 14:50 ` Adrian Bunk 2006-02-25 15:29 ` Jan Engelhardt 2006-02-25 15:40 ` Adrian Bunk 2006-02-25 22:01 ` Jan Engelhardt 2006-02-25 22:07 ` Adrian Bunk 2006-02-25 22:23 ` Dmitry Torokhov 2006-02-26 18:13 ` Adrian Bunk 2006-02-27 7:11 ` Vojtech Pavlik 2006-02-27 12:59 ` Vojtech Pavlik 2006-02-25 14:57 ` Jesper Juhl 2006-02-15 6:20 ` Dmitry Torokhov 2006-02-16 23:22 ` Adrian Bunk 2006-02-17 1:47 ` Dmitry Torokhov -- strict thread matches above, loose matches on Subject: below -- 2006-01-24 18:19 [PATCH] Export symbols so CONFIG_INPUT works as a module Martin Michlmayr 2006-01-24 23:08 ` Dmitry Torokhov 2006-01-24 23:14 ` Martin Michlmayr 2006-01-25 5:04 ` Dmitry Torokhov 2006-02-03 22:36 ` [2.6 patch] make INPUT a bool Adrian Bunk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).