On Wed, Jun 10, 2020 at 09:38:56PM +0200, Thomas Gleixner wrote: > Qian Cai <c...@lca.pw> writes: > > On Tue, Jun 09, 2020 at 10:50:50PM +0200, Thomas Gleixner wrote: > >> Thomas Gleixner <t...@linutronix.de> writes: > >> >> BAD (after oom02) > >> >> # cat /sys/kernel/debug/stackdepot/info > >> >> Unique stacks: 140476 > >> > > >> > That's indeed odd. I try to reproduce and figure out what really breaks > >> > here. > >> > >> I checked your config file and I think I know where this comes from. Can > >> you plase disable KASAN just for testing purposes and compare before > >> after again? > > > > It turns out I'll need a few days to be able to get ahold of those > > affected systems again. I'll be reporting back as soon as possible. > > I figured it out. It has nothing to do with asm_call_on...(). It's also > unrelated to page_owner. It's purely a KASAN issue. > > KASAN trims stack traces with the help of filter_irq_stacks() which > relies on __irqentry_text_start/end > > The entry rework moved the interrupt entry points out of the irqentry > section, which breaks that filter function. > > I made it work again. Here are the numbers which make that obvious: > > Mainline: > Unique stacks: 23403 > Depot index: 244 > Depot offset: 4208 > > x86/entry: > Unique stacks: 38835 > Depot index: 464 > Depot offset: 7616 > > x86/entry + fix: > Unique stacks: 23607 > Depot index: 247 > Depot offset: 14224 > > So with the non-working trimming this generates more unique stacks and > because they are not trimmed they become larger and eat more storage > space. The resulting average per stack shows that: > > Mainline: 171 bytes per stack > x86/entry: 195 bytes per stack > x86/entry + fix: 172 bytes per stack > > I'll point you to a test branch shortly.
Thomas, I get ahold of one of the affected systems now if you want some testing there.
