From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: [lm-sensors] [patch 2.6.27-rc7] i2c: smbalert# support Date: Thu, 20 Nov 2008 14:56:36 -0800 Message-ID: <200811201456.36551.david-b@pacbell.net> References: <200804161434.54335.laurentp@cse-semaphore.com> <20081119161632.2d0bde9e@hyperion.delvare> Reply-To: dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Content-Disposition: inline Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Trent Piepho Cc: Jean Delvare , Linux I2C , lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org List-Id: linux-i2c@vger.kernel.org On Thursday 20 November 2008, Trent Piepho wrote: > > > > Did you actually check the size increase? struct i2c_driver is adde= d > > one pointer, so 4 or 8 bytes, hardly worth mentioning. struct > > i2c_adapter is added 72 bytes on x86-64, to 1360 bytes initially so= an > > increase of less than 6%. Is this really such a big issue? I doubt = it. > > You don't have that many i2c_adapters registered on any given syste= m > > for it to really matter, methinks. >=20 > Except every other subsystem in the kernel does the same thing. =A0Ea= ch release > of 2.6 is significantly more bloated than the last and this is how it= happens.=20 > One "it's not that much wasted" change at a time. I do recall the "4 MByte performance problem" morphing into the "8 MByt= e" problem, and then into the "16 MByte" version then "32 MByte" -- for UN= IX workstations, including GUI. Today's handhelds are more powerful than those! And the embedded boards I get lately have 128 MB of RAM. The real counter-argument is that memory isn't *that* tight, especially since the hardware capacity is growing. That said, maybe you have a patch to propose which would address the problem of how to *cleanly* make this infrastructure optional? - Dave From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Thu, 20 Nov 2008 22:56:36 +0000 Subject: Re: [lm-sensors] [patch 2.6.27-rc7] i2c: smbalert# support Message-Id: <200811201456.36551.david-b@pacbell.net> List-Id: References: <200804161434.54335.laurentp@cse-semaphore.com> <20081119161632.2d0bde9e@hyperion.delvare> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Trent Piepho Cc: Jean Delvare , Linux I2C , lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org On Thursday 20 November 2008, Trent Piepho wrote: > > > > Did you actually check the size increase? struct i2c_driver is added > > one pointer, so 4 or 8 bytes, hardly worth mentioning. struct > > i2c_adapter is added 72 bytes on x86-64, to 1360 bytes initially so an > > increase of less than 6%. Is this really such a big issue? I doubt it. > > You don't have that many i2c_adapters registered on any given system > > for it to really matter, methinks. >=20 > Except every other subsystem in the kernel does the same thing. =A0Each r= elease > of 2.6 is significantly more bloated than the last and this is how it hap= pens.=20 > One "it's not that much wasted" change at a time. I do recall the "4 MByte performance problem" morphing into the "8 MByte" problem, and then into the "16 MByte" version then "32 MByte" -- for UNIX workstations, including GUI. Today's handhelds are more powerful than those! And the embedded boards I get lately have 128 MB of RAM. The real counter-argument is that memory isn't *that* tight, especially since the hardware capacity is growing. That said, maybe you have a patch to propose which would address the problem of how to *cleanly* make this infrastructure optional? - Dave _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors