linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Chen <vincentc@andestech.com>
To: Palmer Dabbelt <palmer@sifive.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>
Subject: Re: [PATCH] RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y
Date: Thu, 24 Jan 2019 08:30:09 +0800	[thread overview]
Message-ID: <20190124003008.GA31546@andestech.com> (raw)
In-Reply-To: <mhng-fd3c9beb-34ce-40c5-92ce-0a7d76d877aa@palmer-si-x1c4>

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 <vincentc@andestech.com>
> >
> > 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 <linux@roeck-us.net>
> >
> > 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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

      reply	other threads:[~2019-01-24  0:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-03  3:32 [PATCH] RISC-V: Add _TIF_NEED_RESCHED check for kernel thread when CONFIG_PREEMPT=y Vincent Chen
2019-01-03  5:45 ` Guenter Roeck
2019-01-22 18:58   ` Palmer Dabbelt
2019-01-24  0:30     ` Vincent Chen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190124003008.GA31546@andestech.com \
    --to=vincentc@andestech.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@roeck-us.net \
    --cc=palmer@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).