search for: callchain

...ld vgw switcheroo code works a lot more like the new mode based on runtime pm and power domains. With a bit more shuffling I think we can also ditch drm_driver->dev_power_state: - There's one in the intel backlight code, which is annoying, since it's wants to know whether the current callchain is from a vga switcheroo state change. But doable with a little helper. - Most others just want a vga_switcheroo_client_is_off() helper, which should be easy. Some are even entirely redundant, at least from a cursor callchain check. There's no races for these because they only matter d...

...nvkm_vmm_iter() > + * REF_PTES == func == gp100_vmm_pgt_pfn() > + * dma_map_page() > + * > + * This is all just encoding the internal hmm reprensetation into a > + * different nouveau internal representation. > + */ Nice callchain from hell.. Unfortunately such "code listings" tend to get out of date very quickly, so I'm not sure it is worth keeping in the code. What would be really worthile is consolidating the two different sets of defines (NVIF_VMM_PFNMAP_V0_ vs NVKM_VMM_PFN_) to make the code a little eas...

...more like the new mode based on runtime pm and > power domains. > > With a bit more shuffling I think we can also ditch > drm_driver->dev_power_state: > > - There's one in the intel backlight code, which is annoying, since it's > wants to know whether the current callchain is from a vga switcheroo > state change. But doable with a little helper. > > - Most others just want a vga_switcheroo_client_is_off() helper, which > should be easy. Some are even entirely redundant, at least from a cursor > callchain check. There's no races for these b...

...ime pm and > > power domains. > > > > With a bit more shuffling I think we can also ditch > > drm_driver->dev_power_state: > > > > - There's one in the intel backlight code, which is annoying, since it's > > wants to know whether the current callchain is from a vga switcheroo > > state change. But doable with a little helper. > > > > - Most others just want a vga_switcheroo_client_is_off() helper, which > > should be easy. Some are even entirely redundant, at least from a cursor > > callchain check. There&...

...page *page, gfp_t gfp_flags) tree = &BTRFS_I(page->mapping->host)->io_tree; map = &BTRFS_I(page->mapping->host)->extent_tree; + /* + * We need to mask out eg. __GFP_HIGHMEM and __GFP_DMA32 as we''re doing + * slab allocation from alloc_extent_state down the callchain where + * it''d hit a BUG_ON as those flags are not allowed. + */ + gfp_flags &= ~GFP_SLAB_BUG_MASK; + ret = try_release_extent_state(map, tree, page, gfp_flags); if (!ret) return 0; -- 1.7.8 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs"...

...Feb 15 10:48:38 linux1 kernel: 00000001 00000000 00000000 00000000 Feb 15 10:48:38 linux1 kernel: 00000000 00000000 00000000 00000000 Feb 15 10:48:38 linux1 kernel: 00000000 00000000 00000000 00000000 Feb 15 10:48:38 linux1 kernel: Kernel BackChain CallChain BackChain CallCha in Feb 15 10:48:38 linux1 kernel: 00339cf8 0000004c After a few of these messages, the system eventually hangs - No network connection and no ability to enter command...

...;m not convinced it's a "no allocation" path even despite that comment, because it also does a "dma_map_page()" etc, which can cause allocations to do the dma mapping thing afaik. No? Maybe there's some reason why that doesn't happen either, but basically this whole callchain looks *way* to complicated to be used under a core VM spinlock. Linus

...;m not convinced it's a "no allocation" path even despite that comment, because it also does a "dma_map_page()" etc, which can cause allocations to do the dma mapping thing afaik. No? Maybe there's some reason why that doesn't happen either, but basically this whole callchain looks *way* to complicated to be used under a core VM spinlock. Linus

...f456 00c27000 00194f9a 00000001 030d2c80 074ed294 00001899 092ca350 0001f94c 8007f2c8 8007f456 08cefaa8 Kernel ACRS: 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Kernel BackChain CallChain 08cefaa8 [<0007f456>] =journal_forget 08cefb10 [<000744c6>] =ext3_forget 08cefb70 [<000767b4>] =ext3_clear_blocks 08cefbd8 [<000768d4>] =ext3_free_data 08cefc50 [<0007...

On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > their lastclose callbacks. Call it from drm_lastclose(), so that the > driver functions can finally be removed. Only PCI devices with enabled > switcheroo do the delayed switching. The call has no effect on other > hardware. > > v2: >

...r classes etc). All these factors depend on target information. If we want go deeper, we know certain micro architectures uses a stack of call/return pairs to help branch prediction of ret instructions -- such stack has a target specific limit which can be triggered when a callsite is deep in the callchain. Register file size and register pressure increase due to inline comes as another example. Another relevant example is the icache/itlb sizes. To do a more precise analysis of the cost to 'speed' due to icache/itlb pressure increase requires target information, profile information as well...

...on. Btw, console_lock is leaked on an error path. - i915: I think that clearing the fb memory can be done outside the lock too as the console is suspended. Please correct me if my assumptions are flawed. > Besides this, when fixing a deadlock pls provide more details about the > precise callchain and the locks involved in the deadlock. If you > discovered this using lockdep, then just add the entire lockdep splat to > the commit message. Otherwise there's lots of guesswork involved here. > -Daniel There was no lockdep splat, it was triggered via the ioctl in the commit message...

...allocations to do the dma mapping thing afaik. No? Well no because DMA is triggered by the IOMMU flag and that is always off for the balloon. But I hear what you are saying about it being fragile. > Maybe there's some reason why that doesn't happen either, but > basically this whole callchain looks *way* to complicated to be used > under a core VM spinlock. > > Linus Maybe it will help to have GFP_NONE which will make any allocation fail if attempted. Linus, would this address your comment? -- MST

...060134 800601d4 030bdbb8 Kernel ACRS: 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Kernel BackChain CallChain 030bdbb8 ^<000601d4>] 030bdc98 ^<000602ca>] 030bdcf8 ^<0006ab48>] 030bdd58 ^<0005bcfe>] 030bddb8 ^<0005bf36>] 030bde28 ^<0004964a>] 030bdea8 ^<00049b40>] 030bdf08 ^<000128f0>]...

...> + * REF_PTES == func == gp100_vmm_pgt_pfn() > > + * dma_map_page() > > + * > > + * This is all just encoding the internal hmm reprensetation into a > > + * different nouveau internal representation. > > + */ > > Nice callchain from hell.. Unfortunately such "code listings" tend to > get out of date very quickly, so I'm not sure it is worth keeping in > the code. What would be really worthile is consolidating the two > different sets of defines (NVIF_VMM_PFNMAP_V0_ vs NVKM_VMM_PFN_) > to make t...

Philip Reames wrote: > Any change outside of statepoint lowering is highly suspect. Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying) has exactly one other caller: visitCall, which doesn't match vararg functions. Every other codepath directly calls TargetLowering::LowerCallTo, supplying CallLoweringInfo information explicity (it's a structure with a vararg

...le-parsing.c | 2 +- tools/perf/ui/browser.h | 4 +- tools/perf/ui/progress.h | 2 +- tools/perf/util/annotate.h | 2 +- tools/perf/util/build-id.h | 2 +- tools/perf/util/callchain.h | 7 + tools/perf/util/dso.h | 2 +- tools/perf/util/event.h | 24 ++ tools/perf/util/evsel.h | 4 +- tools/perf/util/header.h | 4 +- tools/perf/util/inclu...

...le-parsing.c | 2 +- tools/perf/ui/browser.h | 4 +- tools/perf/ui/progress.h | 2 +- tools/perf/util/annotate.h | 2 +- tools/perf/util/build-id.h | 2 +- tools/perf/util/callchain.h | 7 + tools/perf/util/dso.h | 2 +- tools/perf/util/event.h | 24 ++ tools/perf/util/evsel.h | 4 +- tools/perf/util/header.h | 4 +- tools/perf/util/inclu...

...> > > Please correct me if my assumptions are flawed. > > Yeah, fixing this independent issues should definitely help, irrespective > of how we fix fb_set_suspend. > > > > Besides this, when fixing a deadlock pls provide more details about the > > > precise callchain and the locks involved in the deadlock. If you > > > discovered this using lockdep, then just add the entire lockdep splat to > > > the commit message. Otherwise there's lots of guesswork involved here. > > > -Daniel > > > > There was no lockdep splat, it...

...k too as the console is suspended. > > Please correct me if my assumptions are flawed. Yeah, fixing this independent issues should definitely help, irrespective of how we fix fb_set_suspend. > > Besides this, when fixing a deadlock pls provide more details about the > > precise callchain and the locks involved in the deadlock. If you > > discovered this using lockdep, then just add the entire lockdep splat to > > the commit message. Otherwise there's lots of guesswork involved here. > > -Daniel > > There was no lockdep splat, it was triggered via the io...