Subject: Re: XFS stack overhead - msg#08763

Previous Message by Date: click to view message preview

Re: [Discuss] [PATCH] ipmi: use round_jiffies on timers to reduce timer overhead/wakeups

Randy Dunlap wrote: On Wed, 21 Oct 2009 11:49:59 -0700 Kok, Auke wrote: Arjan van de Ven wrote: On Wed, 21 Oct 2009 10:28:22 -0700 Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote: From: Randy Dunlap <randy.dunlap@xxxxxxxxxx> Use a round_jiffies() variant to reduce overhead of timer wakeups. This causes the ipmi timers to occur at the same time as other timers (per CPU). Typical powertop for /ipmi/ (2.6.31, before patch): 11.4% (247.4) kipmi0 : __mod_timer (process_timeout) 0.6% ( 13.1) <interrupt> : ipmi_si 0.5% ( 10.0) <kernel core> : __mod_timer (ipmi_timeout) powertop for /ipmi/, 2.6.31, after patch: 10.8% (247.6) kipmi0 : __mod_timer (process_timeout) 0.3% ( 6.9) <interrupt> : ipmi_si 0.0% ( 1.0) <kernel core> : __mod_timer (ipmi_timeout) while it is nice that ipmi_si ande the timer wake up less now.... it's still rather sad that the 247.6 from kipmi0 are still there..... those are a much much bigger issue obviously :) Randy, any idea where those are coming from ? obviously from kipmi thread :( drivers/char/ipmi/ipmi_si_intf.c::ipmi_thread(): static int ipmi_thread(void *data) { struct smi_info *smi_info = data; unsigned long flags; enum si_sm_result smi_result; set_user_nice(current, 19); while (!kthread_should_stop()) { spin_lock_irqsave(&(smi_info->si_lock), flags); smi_result = smi_event_handler(smi_info, 0); spin_unlock_irqrestore(&(smi_info->si_lock), flags); if (smi_result == SI_SM_CALL_WITHOUT_DELAY) ; /* do nothing */ else if (smi_result == SI_SM_CALL_WITH_DELAY) schedule(); else schedule_timeout_interruptible(1); <----- } return 0; } calls setup_timer_on_stack(), which calls process_timeout(). From what I recall (probably 2 years ago), [older] ipmi hardware does not generate event interrupts, so it has to be polled. Corey, can you elaborate on this? Certainly. Yes, some (probably most) IPMI hardware does not use interrupts, and unfortunately, it's not just older machines. The driver used to poll more slowly, but in many cases the performance was unacceptable. kipmid is only started if the hardware doesn't support interrupts, so only users with sub-standard hardware have to suffer with this problem. Thanks for the patch, Randy. -corey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Next Message by Date: click to view message preview

Re: [PATCH] leds-alix2: add support for button connected to J15

On Thu, Oct 22, 2009 at 01:21:21AM +0500, Constantin Baranov wrote: > I wonder why do you integrate the input driver into the leds driver. They > should be separated. Or at least the complex driver should be moved to the > "X86 Platform Specific Device Drivers" and renamed to some like "PC Engines > ALIX Extras". I personally would prefer the separation way. I would as well, yes. And I was of course considerating this when I hacked these lines. However, the major part of the LED driver and what it currently shares with the button implementation is the BIOS detection code which is so ugly that I didn't want to duplicate it ;) That would, however, be the only option if you wanted to split the drivers up. Or do you have any better idea? > Also ALIX.2 documentation describes the "Mode switch" driven by GPIO which is > a > small button on front side of a board. I guessed your driver is not for this > button. If so, would it be better to provide the mode switch as KEY_PROG1 and > the J15 connected button as KEY_PROG2 at once? Correct, the button this code is for is not the one on the 'front' side of the PCB. The other one I didn't try yet, but according the the CS5536A datasheet, the alternate function for that pin is WORK_AUX which can be used for power switching purposes. So that might need some extra care probably. However, if you can make any suggestion of how to split the code without copying more than half of the lines for that, I'd be happy with that as well, of course :) Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Previous Message by Thread: click to view message preview

Re: XFS stack overhead

Ingo Molnar wrote: > * Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > >> Arjan van de Ven wrote: >>> On Wed, 21 Oct 2009 10:50:02 -0500 >>> Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >>> >>>> Ingo Molnar wrote: >>>>> (Cc:-ed Arjan too.) >>>>> >>>>> * Dave Jones <davej@xxxxxxxxxx> wrote: >>>>> >>>>>> 113c5413cf9051cc50b88befdc42e3402bb92115 introduced a change that >>>>>> made CC_STACKPROTECTOR_ALL not-selectable if someone enables >>>>>> CC_STACKPROTECTOR. >>>>>> >>>>>> We've noticed in Fedora that this has introduced noticable >>>>>> overhead on some functions, including those which don't even have >>>>>> any on-stack variables. >>>>>> >>>>>> According to the gcc manpage, -fstack-protector will protect >>>>>> functions with as little as 8 bytes of stack usage. So we're >>>>>> introducing a huge amount of overhead, to close a small amount of >>>>>> vulnerability (the >0 && <8 case). >>>>>> >>>>>> The overhead as it stands right now means this whole option is >>>>>> unusable for a distro kernel without reverting the above commit. >>>>> Exactly what workload showed overhead, and how much? >>>>> >>>>> Ingo >>>> I had xfs blowing up pretty nicely; granted, xfs is not svelte but it >>>> was never this bad before. >>>> >>> do you have any indication that SP actually increases the stack >>> footprint by that much? it's only a few bytes.... >>> >>> >> Here's a sample of some of the largest xfs stack users, >> and the effect stack-protector had on them. This was just >> done with objdump -d xfs.ko | scripts/checkstack.pl; I don't >> know if there's extra runtime stack overhead w/ stackprotector? >> >> -Eric >> >> function nostack stackprot delta delta % >> xfs_bmapi 376 408 32 9% >> xfs_bulkstat 328 344 16 5% >> _xfs_trans_commit 296 312 16 5% >> xfs_iomap_write_delay 264 280 16 6% >> xfs_file_ioctl 248 312 64 26% >> xfs_symlink 248 264 16 6% >> xfs_bunmapi 232 280 48 21% >> xlog_do_recovery_pass 232 248 16 7% >> xfs_trans_unreserve_and_mod_sb 224 240 16 7% >> xfs_bmap_del_extent 216 248 32 15% >> xfs_cluster_write 216 232 16 7% >> xfs_file_compat_ioctl 216 296 80 37% >> xfs_attr_set_int 200 216 16 8% >> xfs_bmap_add_extent_delay_real 200 248 48 24% > > Note that those are very large stack frames to begin with. > > 3496 bytes - that's a _lot_ - can anyone even run XFS with 4K stacks on? The above isn't a callchain; those are just the biggest users. Yes, xfs works w/4k stacks but sometimes not over complex storage. > With stackprotector it's 3928 - a 12% increase - which certainly does > not help - but the basic problem is the large stack footprint to begin > with. I can find plenty of examples of > 300 bytes stack users in the core kernel write path too, I'm just using xfs as an example... > Also, the posting apparently mixes 'stack overhead' with 'runtime > overhead'. right, that's why I asked, I'm not sure if stackprotector has runtime overhead as well. -Eric > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Next Message by Thread: click to view message preview

Re: Unnecessary overhead with stack protector.

On Thu, 15 Oct 2009 14:35:41 -0400 Dave Jones <davej@xxxxxxxxxx> wrote: > 113c5413cf9051cc50b88befdc42e3402bb92115 introduced a change that > made CC_STACKPROTECTOR_ALL not-selectable if someone enables > CC_STACKPROTECTOR. > > We've noticed in Fedora that this has introduced noticable overhead on > some functions, including those which don't even have any on-stack variables. > > According to the gcc manpage, -fstack-protector will protect functions with > as little as 8 bytes of stack usage. So we're introducing a huge amount > of overhead, to close a small amount of vulnerability (the >0 && <8 case). > > The overhead as it stands right now means this whole option is unusable for > a distro kernel without reverting the above commit. > This looks like a fairly serious problem to me, but I'm confused by the commit ID. February 2008 - is this correct? If so, this seems like a rather long period of time in which to make such a discovery. Also, the Kconfig fiddle didn't cause the problem - it just revealed it. The core problem of increased stack usage and text size should already have been known (to stackprotector developers, at least). But it sounds like it wasn't. So perhaps this was all triggered by a particular gcc version? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/