[PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
This doesn't seem to be used anywhere Cc: Andrew Morton Cc: Kees Cook Cc: Johannes Weiner Cc: Tejun Heo Cc: Arnd Bergmann Cc: Petr Mladek Cc: Ard Biesheuvel Cc: Thomas Garnier Cc: Nicolas Pitre Cc: Peter Zijlstra Cc: linux-snps-arc@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Vineet Gupta --- init/Kconfig | 13 - 1 file changed, 13 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index cac3f096050d..934a61f6e2cc 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1707,19 +1707,6 @@ config PERF_EVENTS Say Y if unsure. -config DEBUG_PERF_USE_VMALLOC - default n - bool "Debug: use vmalloc to back perf mmap() buffers" - depends on PERF_EVENTS && DEBUG_KERNEL && !PPC - select PERF_USE_VMALLOC - help -Use vmalloc memory to back perf mmap() buffers. - -Mostly useful for debugging the vmalloc code on platforms -that don't require it. - -Say N if unsure. - endmenu config VM_EVENT_COUNTERS -- 2.7.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
On Tue, 27 Sep 2016 07:53:56 -0700 Vineet Gupta wrote: > This doesn't seem to be used anywhere I thought so too, until I got this response for an equivalent patch: https://lkml.org/lkml/2016/8/31/53 Kim ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
On 09/27/2016 09:37 AM, Kim Phillips wrote: > On Tue, 27 Sep 2016 07:53:56 -0700 > Vineet Gupta wrote: > >> > This doesn't seem to be used anywhere > I thought so too, until I got this response for an equivalent patch: > > https://lkml.org/lkml/2016/8/31/53 So this is some sort of "developer shortcut" to quickly enable 2 options with one option. Purpose seems dubious to me ! It would still be possible to enable vmalloc backed mmap on x86 by simply enabling that option from Kconfig. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: NMI for ARC
Hi Peter, On 11/17/2015 05:15 AM, Peter Zijlstra wrote: > On Tue, Nov 17, 2015 at 06:23:21PM +0530, Vineet Gupta wrote: >> On Tuesday 17 November 2015 05:55 PM, Peter Zijlstra wrote: >> >>> This is assuming you now have these NMIs we talked about earlier. If all >>> you have are regular IRQs this is not possible, for we should be calling >>> ->read() with IRQs disabled. >>> >> >> No we don't yet. The first stab at it fell flat on floor. >> >> The NMI support from hardware is that is it provides different priorities, >> higher >> one obviously able to interrupt lower one. However instructions like CLRI >> (disable >> interrupts) will still lock out all interrupts. >> >> Thus local_irq_save()/restore() and local_irq_enable()/disable() now need to >> be >> contextual. >> >> - When running in prio 0 mode, they only need to enable 0 >> - In prio 1, they need to enable both 0 and 1 >> >> For irq_save()/restore() this is achievable by doing an additional STATUS32 >> read >> at the time of save and passing that value to restore - so there's an >> additional >> overhead - but ignoring that for now. >> >> Bummer is irq_disable()/enable() case: there's need to pass old prio state >> from >> enable to disabled, so we need some sort of global state tracking - which in >> case >> of SMP needs to be per cpu either keep something hot in a reg or pay the >> cost >> of additional mem/cache line miss. >> >> I've not investigated how other arches do that. PPC seems to be using some >> sort of >> soft irq state anyways. > > Yeah, Sparc64 might be a better example, it more closely matches your > hardware. See > arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save(). So I finally got around to doing this and as expected has turned out to be quite some fun. I have a couple of questions and would really appreciate your inputs there. 1. Is it OK in general to short-circuit preemption off irq checks for NMI style interrupts. The issue is we can get nested interrupts (timer followed by perf) and one of them can cause resched_curr() to a user task - but we can't return to user mode from inner interrupt. So it becomes easy if we don't even bother checking for TIF_NEED_RESCHED in perf intr path. This also has slight advantage that perf intr returns quickly. Implementation wise this requires a hack to bump preemption count in the low level nmi handler - and revert that in nmi return path. 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode require interrupt safety, does that need to be NMI safe as well. We ofcourse want the very late register restore parts to be non-interruptible, but is this required before we call prrempt_schedule_irq() off of asm code. Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
On Tue, Sep 27, 2016 at 09:51:35AM -0700, Vineet Gupta wrote: > On 09/27/2016 09:37 AM, Kim Phillips wrote: > > On Tue, 27 Sep 2016 07:53:56 -0700 > > Vineet Gupta wrote: > > > >> > This doesn't seem to be used anywhere > > I thought so too, until I got this response for an equivalent patch: > > > > https://lkml.org/lkml/2016/8/31/53 > > So this is some sort of "developer shortcut" to quickly enable 2 options with > one > option. Purpose seems dubious to me ! It would still be possible to enable > vmalloc > backed mmap on x86 by simply enabling that option from Kconfig. PERF_USE_VMALLOC is not a user selectable option. Also DEBUG_PERF_USE_VMALLOC clearly indicates its a _DEBUG_ option. Heck, even the help text says what its for. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
