lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <200711051305.13980.david-b@pacbell.net> Date: Mon, 5 Nov 2007 13:05:13 -0800 From: David Brownell <david-b@...bell.net> To: Linux Kernel list <linux-kernel@...r.kernel.org> Cc: Felipe Balbi <felipebalbi@...rs.sourceforge.net>, Bill Gatliff <bgat@...lgatliff.com>, Haavard Skinnemoen <hskinnemoen@...el.com>, Andrew Victor <andrew@...people.com>, Tony Lindgren <tony@...mide.com>, Jean Delvare <khali@...ux-fr.org>, "eric miao" <eric.y.miao@...il.com>, Kevin Hilman <khilman@...sta.com>, Paul Mundt <lethal@...ux-sh.org>, Ben Dooks <ben@...nity.fluff.org> Subject: Re: [patch/rfc 1/4] GPIO implementation framework On Monday 29 October 2007, David Brownell wrote: > > Provides new implementation infrastructure that platforms may choose to use > when implementing the GPIO programming interface. Platforms can update their > GPIO support to use this. The downside is slower access to non-inlined GPIOs; > rarely a problem except when bitbanging some protocol. I was asked just what that overhead *is* ... and it surprised me. A summary of the results is appended to this note. Fortuntely it turns out those problems all go away if the gpiolib code uses a *raw* spinlock to guard its table lookups. With a raw spinlock, any performance impact of gpiolib seems to be well under a microsecond in this bitbang context (and not objectionable). Preempt became free; enabling debug options had only a minor cost. That's as it should be, since the only substantive changes were to grab and release a lock, do one table lookup a bit differently, and add one indirection function call ... changes which should not have any visible performance impact on per-bit codepaths, and one might expect to cost on the order of one dozen instructions. So the next version of this code will include a few minor bugfixes, and will also use a raw spinlock to protect that table. A raw lock seems appropriate there in any case, since non-sleeping GPIOs should be accessible from hardirq contexts even on RT kernels. If anyone has any strong arguments against using a raw spinlock to protect that table, it'd be nice to know them sooner rather than later. - Dave SUMMARY: Using the i2c-gpio driver on a preempt kernel with all the usual kernel debug options enabled, the per-bit times (*) went up in a bad way: from about 6.4 usec/bit (original GPIO code on this board) up to about 11.2 usec/bit (just switching to gpiolib), which is well into "objectionable overhead" territory for bit access. Just enabling preempt shot the time up to 7.4 usec/bit ... which is also objectionable (it's all-the-time overhead that is clearly needless), but much less so. Converting the table lock to be a raw spinlock essentially removed all non-debug overheads. It took enabling all those debug options plus internal gpiolib debugging overhead to get those times up to the 7.4 usec/bit that previously applied even with just preempt. (*) Those times being eyeballed medians; I didn't make time to find a way to export a few thousand measurements from the tool and do the math. The typical range was +/- one usec. The numbers include udelay() calls, so the relevant point is the time *delta* attributable only to increased gpiolib costs, not the base time (with udelays). The delta probably reflects on the order of four GPIO calls: set two different bits, clear one of them, and read it to make sure it cleared. > The upside is: > > * Providing two features which were "want to have (but OK to defer)" when > GPIO interfaces were first discussed in November 2006: > > - A "struct gpio_chip" to plug in GPIOs that aren't directly supported > by SOC platforms, but come from FPGAs or other multifunction devices > (like UCB-1x00 GPIOs). > > - Full support for message-based GPIO expanders, needing a gpio_chip > hookup; previous support for this part of the programming interface > was just stubs. (One example: the widely used pcf8574 I2C chips, > with 8 GPIOs each.) > > * Including a non-stub implementation of the gpio_{request,free}() calls, > which makes those calls much more useful. The diagnostic labels are > also recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a > snapshot of all GPIOs known to this infrastructure. > > The driver programming interfaces introduced in 2.6.21 do not change at all; > this new infrastructure is entirely below the covers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists