From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH v6 17/18] mm/memory-failure: increase queued recovery work's priority Date: Tue, 16 Oct 2018 09:43:51 +0200 Message-ID: <20181016074351.GC4030@hirez.programming.kicks-ass.net> References: <20180921221705.6478-1-james.morse@arm.com> <20180921221705.6478-18-james.morse@arm.com> <20181015164913.GE11434@zn.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20181015164913.GE11434@zn.tnic> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Borislav Petkov Cc: jonathan.zhang@cavium.com, Rafael Wysocki , Tony Luck , Xie XiuQi , linux-mm@kvack.org, Marc Zyngier , Catalin Marinas , Tyler Baicar , Will Deacon , Christoffer Dall , Dongjiu Geng , linux-acpi@vger.kernel.org, Punit Agrawal , James Morse , Naoya Horiguchi , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Len Brown List-Id: linux-acpi@vger.kernel.org On Mon, Oct 15, 2018 at 06:49:13PM +0200, Borislav Petkov wrote: > On Fri, Sep 21, 2018 at 11:17:04PM +0100, James Morse wrote: > > @@ -1463,11 +1465,14 @@ void memory_failure_queue(unsigned long pfn, int flags) > > > > mf_cpu = &get_cpu_var(memory_failure_cpu); > > spin_lock_irqsave(&mf_cpu->lock, proc_flags); > > - if (kfifo_put(&mf_cpu->fifo, entry)) > > - schedule_work_on(smp_processor_id(), &mf_cpu->work); > > - else > > + if (kfifo_put(&mf_cpu->fifo, entry)) { > > + queue_work_on(cpu, system_highpri_wq, &mf_cpu->work); > > + set_tsk_need_resched(current); > > + preempt_set_need_resched(); > > What guarantees the workqueue would run before the process? I see this: > > ``WQ_HIGHPRI`` > Work items of a highpri wq are queued to the highpri > worker-pool of the target cpu. Highpri worker-pools are > served by worker threads with elevated nice level. > > but is that enough? Nope. Nice just makes it more likely, but no guarantees what so ever. If you want to absolutely run something before we return to userspace, would not task_work() be what we're looking for? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 9BBA66B0006 for ; Tue, 16 Oct 2018 03:44:15 -0400 (EDT) Received: by mail-pf1-f199.google.com with SMTP id b27-v6so22643065pfm.15 for ; Tue, 16 Oct 2018 00:44:15 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2607:7c80:54:e::133]) by mx.google.com with ESMTPS id o5-v6si12871518plk.95.2018.10.16.00.44.14 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Oct 2018 00:44:14 -0700 (PDT) Date: Tue, 16 Oct 2018 09:43:51 +0200 From: Peter Zijlstra Subject: Re: [PATCH v6 17/18] mm/memory-failure: increase queued recovery work's priority Message-ID: <20181016074351.GC4030@hirez.programming.kicks-ass.net> References: <20180921221705.6478-1-james.morse@arm.com> <20180921221705.6478-18-james.morse@arm.com> <20181015164913.GE11434@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181015164913.GE11434@zn.tnic> Sender: owner-linux-mm@kvack.org List-ID: To: Borislav Petkov Cc: James Morse , linux-acpi@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, Marc Zyngier , Christoffer Dall , Will Deacon , Catalin Marinas , Naoya Horiguchi , Rafael Wysocki , Len Brown , Tony Luck , Tyler Baicar , Dongjiu Geng , Xie XiuQi , Punit Agrawal , jonathan.zhang@cavium.com On Mon, Oct 15, 2018 at 06:49:13PM +0200, Borislav Petkov wrote: > On Fri, Sep 21, 2018 at 11:17:04PM +0100, James Morse wrote: > > @@ -1463,11 +1465,14 @@ void memory_failure_queue(unsigned long pfn, int flags) > > > > mf_cpu = &get_cpu_var(memory_failure_cpu); > > spin_lock_irqsave(&mf_cpu->lock, proc_flags); > > - if (kfifo_put(&mf_cpu->fifo, entry)) > > - schedule_work_on(smp_processor_id(), &mf_cpu->work); > > - else > > + if (kfifo_put(&mf_cpu->fifo, entry)) { > > + queue_work_on(cpu, system_highpri_wq, &mf_cpu->work); > > + set_tsk_need_resched(current); > > + preempt_set_need_resched(); > > What guarantees the workqueue would run before the process? I see this: > > ``WQ_HIGHPRI`` > Work items of a highpri wq are queued to the highpri > worker-pool of the target cpu. Highpri worker-pools are > served by worker threads with elevated nice level. > > but is that enough? Nope. Nice just makes it more likely, but no guarantees what so ever. If you want to absolutely run something before we return to userspace, would not task_work() be what we're looking for? From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Tue, 16 Oct 2018 09:43:51 +0200 Subject: [PATCH v6 17/18] mm/memory-failure: increase queued recovery work's priority In-Reply-To: <20181015164913.GE11434@zn.tnic> References: <20180921221705.6478-1-james.morse@arm.com> <20180921221705.6478-18-james.morse@arm.com> <20181015164913.GE11434@zn.tnic> Message-ID: <20181016074351.GC4030@hirez.programming.kicks-ass.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 15, 2018 at 06:49:13PM +0200, Borislav Petkov wrote: > On Fri, Sep 21, 2018 at 11:17:04PM +0100, James Morse wrote: > > @@ -1463,11 +1465,14 @@ void memory_failure_queue(unsigned long pfn, int flags) > > > > mf_cpu = &get_cpu_var(memory_failure_cpu); > > spin_lock_irqsave(&mf_cpu->lock, proc_flags); > > - if (kfifo_put(&mf_cpu->fifo, entry)) > > - schedule_work_on(smp_processor_id(), &mf_cpu->work); > > - else > > + if (kfifo_put(&mf_cpu->fifo, entry)) { > > + queue_work_on(cpu, system_highpri_wq, &mf_cpu->work); > > + set_tsk_need_resched(current); > > + preempt_set_need_resched(); > > What guarantees the workqueue would run before the process? I see this: > > ``WQ_HIGHPRI`` > Work items of a highpri wq are queued to the highpri > worker-pool of the target cpu. Highpri worker-pools are > served by worker threads with elevated nice level. > > but is that enough? Nope. Nice just makes it more likely, but no guarantees what so ever. If you want to absolutely run something before we return to userspace, would not task_work() be what we're looking for?