Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1392052imu; Wed, 23 Jan 2019 16:31:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN5bIAPttUxsD+VFHOj4Sl7vkT7X/CwCT6GN08UwIrZClb7vIzRD2nyKC1pIpJLny5aYxapq X-Received: by 2002:a63:680a:: with SMTP id d10mr4014937pgc.396.1548289880754; Wed, 23 Jan 2019 16:31:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548289880; cv=none; d=google.com; s=arc-20160816; b=yu74BlJCUGxjScsDNnW17uLML4z0f+2NPzc/0b+2x1NMzFO2mtUywAi+2v5cRdeGge 2VC9Y/qfnN0GqosnrZVwvDzIJSBiQHZau0SZPPG1rnNZOyVkPR7K8qTP/XKYHP81TiEP YLPTb71/igVC1l8rPTRfi3xD3VH5QuJKm+VdWulQPI5f4HK/VwzMfe+RW/qe16SRfRQl wRIac2SREPRPkXhDDdWtF8PsDyhQi4Y/mgv8KgESQa1JqzEWrSWAYLifOr54A43WMgTp Rz5NM9OicK1Vy8OKEZ5+a7M5iD/tt+kR3oYQGa5MYsd04ObsYDVy2mfiDqy40tvwmna6 zOHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=lmuDXyx1Z+EcyZifyh3nVK9loFzbsd9kREuhkb+pbLw=; b=Q9AOBmVHh7JqMwLE3S7FRScTh6fVuv1HgGSWts61BrdLU4tQtEpFvZa8ol+Fs8v5Kc PkjzDOe5kA7nZr1jgty9hHS/puEkU0AhTDW0JDydH2A4FHREwpzBUdMSWrnnfooUbIcx P3MVc1LTuMqSJTtpiqomO3PKhARWWn+J3AE3u5MmzAlPPFpGBFkwYM/6elGCow6bSb8p r99Fa5KW6ZuGhgex0d5fsi5/1ncbns+C2RTwHT4b2lceQ9gg7oWw9Yh6taIVmQNqTdh7 74j8YkFCa1mIo7zEhOcBE/Ag4/abScOUftI+7Bnao9yggV8w3cd4OJTyJya6gqXN2d2L oOBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x5si20313428pgq.535.2019.01.23.16.31.04; Wed, 23 Jan 2019 16:31:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726324AbfAXAa6 (ORCPT + 99 others); Wed, 23 Jan 2019 19:30:58 -0500 Received: from 59-120-53-16.HINET-IP.hinet.net ([59.120.53.16]:40333 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726168AbfAXAa6 (ORCPT ); Wed, 23 Jan 2019 19:30:58 -0500 Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id x0O0WMwG060590; Thu, 24 Jan 2019 08:32:22 +0800 (GMT-8) (envelope-from vincentc@andestech.com) Received: from andestech.com (10.0.15.65) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.123.3; Thu, 24 Jan 2019 08:30:12 +0800 Date: Thu, 24 Jan 2019 08:30:09 +0800 From: Vincent Chen To: Palmer Dabbelt CC: "linux@roeck-us.net" , "aou@eecs.berkeley.edu" , "linux-riscv@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann , "linux-arch@vger.kernel.org" Subject: Re: [PATCH] RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y Message-ID: <20190124003008.GA31546@andestech.com> References: <20190103054555.GA30904@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.0.15.65] X-DNSRBL: X-MAIL: ATCSQR.andestech.com x0O0WMwG060590 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 23, 2019 at 02:58:51AM +0800, Palmer Dabbelt wrote: > On Wed, 02 Jan 2019 21:45:55 PST (-0800), linux@roeck-us.net wrote: > > On Thu, Jan 03, 2019 at 11:32:33AM +0800, Vincent Chen wrote: > >> The cond_resched() can be used to yield the CPU resource if > >> CONFIG_PREEMPT is not defined. Otherwise, cond_resched() is a dummy > >> function. In order to avoid kernel thread occupying entire CPU, > >> when CONFIG_PREEMPT=y, the kernel thread needs to follow the > >> rescheduling mechanism like a user thread. > >> > >> Signed-off-by: Vincent Chen > > > > This patch seems to do the trick. I no longer see a problem with > > CONFIG_PREEMPT=y and the various lock torture tests enabled, as > > previously reported. > > > > Nice catch and fix. > > > > Tested-by: Guenter Roeck > > > > Guenter > > > >> --- > >> arch/riscv/kernel/asm-offsets.c | 1 + > >> arch/riscv/kernel/entry.S | 18 +++++++++++++++++- > >> 2 files changed, 18 insertions(+), 1 deletions(-) > >> > >> diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c > >> index 6a92a2f..dac9834 100644 > >> --- a/arch/riscv/kernel/asm-offsets.c > >> +++ b/arch/riscv/kernel/asm-offsets.c > >> @@ -39,6 +39,7 @@ void asm_offsets(void) > >> OFFSET(TASK_STACK, task_struct, stack); > >> OFFSET(TASK_TI, task_struct, thread_info); > >> OFFSET(TASK_TI_FLAGS, task_struct, thread_info.flags); > >> + OFFSET(TASK_TI_PREEMPT_COUNT, task_struct, thread_info.preempt_count); > >> OFFSET(TASK_TI_KERNEL_SP, task_struct, thread_info.kernel_sp); > >> OFFSET(TASK_TI_USER_SP, task_struct, thread_info.user_sp); > >> OFFSET(TASK_TI_CPU, task_struct, thread_info.cpu); > >> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > >> index 13d4826..728b72d 100644 > >> --- a/arch/riscv/kernel/entry.S > >> +++ b/arch/riscv/kernel/entry.S > >> @@ -144,6 +144,10 @@ _save_context: > >> REG_L x2, PT_SP(sp) > >> .endm > >> > >> +#if !IS_ENABLED(CONFIG_PREEMPT) > >> +#define resume_kernel restore_all > >> +#endif > >> + > > I don't like preprocessor stuff if we can avoid it, are you OK if I squash in > the following diff: > > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > index cfbad2f689c3..fd9b57c8b4ce 100644 > --- a/arch/riscv/kernel/entry.S > +++ b/arch/riscv/kernel/entry.S > @@ -145,7 +145,7 @@ _save_context: > .endm > > #if !IS_ENABLED(CONFIG_PREEMPT) > -#define resume_kernel restore_all > +.set resume_kernel, restore_all > #endif > > ENTRY(handle_exception) > > I think that should do the same thing, but at link time instead of in the > preprocessor -- that makes it a bit less likely to bit us in the future. > > >> ENTRY(handle_exception) > >> SAVE_ALL > >> > >> @@ -228,7 +232,7 @@ ret_from_exception: > >> REG_L s0, PT_SSTATUS(sp) > >> csrc sstatus, SR_SIE > >> andi s0, s0, SR_SPP > >> - bnez s0, restore_all > >> + bnez s0, resume_kernel > >> > >> resume_userspace: > >> /* Interrupts must be disabled here so flags are checked atomically */ > >> @@ -250,6 +254,18 @@ restore_all: > >> RESTORE_ALL > >> sret > >> > >> +#if IS_ENABLED(CONFIG_PREEMPT) > >> +resume_kernel: > >> + REG_L s0, TASK_TI_PREEMPT_COUNT(tp) > >> + bnez s0, restore_all > >> +need_resched: > >> + REG_L s0, TASK_TI_FLAGS(tp) > >> + andi s0, s0, _TIF_NEED_RESCHED > >> + beqz s0, restore_all > >> + call preempt_schedule_irq > >> + j need_resched > >> +#endif > >> + > >> work_pending: > >> /* Enter slow path for supplementary processing */ > >> la ra, ret_from_exception > > I'm just going to assume you're OK with the squash and drop this into my plans > for the next RC, let me know if that's not OK. > > Thanks for fixing this! OK, it's fine for me. Vincent