All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
	linux-kernel@vger.kernel.org
Cc: Julien Thierry <julien.thierry@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-xtensa@linux-xtensa.org, x86@kernel.org,
	sparclinux@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-mips@vger.kernel.org,
	uclinux-h8-devel@lists.sourceforge.jp,
	linux-c6x-dev@linux-c6x.org, linux-ia64@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-m68k@lists.linux-m68k.org,
	nios2-dev@lists.rocketboards.org
Subject: Re: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub
Date: Tue, 12 Mar 2019 18:03:55 +0000	[thread overview]
Message-ID: <e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com> (raw)
In-Reply-To: <20190311224752.8337-1-valentin.schneider@arm.com>

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>    preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>    and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
	<linux-kernel@vger.kernel.org>
Cc: Julien Thierry <julien.thierry@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	<linux-xtensa@linux-xtensa.org>, <x86@kernel.org>,
	<sparclinux@vger.kernel.org>, <linux-sh@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>,
	<linuxppc-dev@lists.ozlabs.org>, <linux-mips@vger.kernel.org>,
	<uclinux-h8-devel@lists.sourceforge.jp>,
	<linux-c6x-dev@linux-c6x.org>, <linux-ia64@vger.kernel.org>,
	<linux-s390@vger.kernel.org>,
	<linux-snps-arc@lists.infradead.org>,
	<linux-m68k@lists.linux-m68k.org>,
	<nios2-dev@lists.rocketboards.org>
Subject: Re: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub
Date: Tue, 12 Mar 2019 11:03:55 -0700	[thread overview]
Message-ID: <e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com> (raw)
In-Reply-To: <20190311224752.8337-1-valentin.schneider@arm.com>

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>    preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>    and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
	linux-kernel@vger.kernel.org
Cc: Julien Thierry <julien.thierry@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-xtensa@linux-xtensa.org, x86@kernel.org,
	sparclinux@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-mips@vger.kernel.org,
	uclinux-h8-devel@lists.sourceforge.jp,
	linux-c6x-dev@linux-c6x.org, linux-ia64@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-m68k@lists.linux-m68k.org,
	nios2-dev@lists.rocketboards.org
Subject: Re: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub
Date: Tue, 12 Mar 2019 11:03:55 -0700	[thread overview]
Message-ID: <e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com> (raw)
In-Reply-To: <20190311224752.8337-1-valentin.schneider@arm.com>

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>    preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>    and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
	<linux-kernel@vger.kernel.org>
Cc: uclinux-h8-devel@lists.sourceforge.jp,
	linux-xtensa@linux-xtensa.org, linux-ia64@vger.kernel.org,
	linux-c6x-dev@linux-c6x.org,
	Julien Thierry <julien.thierry@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-s390@vger.kernel.org, x86@kernel.org,
	linux-mips@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	Ingo Molnar <mingo@redhat.com>,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	nios2-dev@lists.rocketboards.org,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-snps-arc@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub
Date: Tue, 12 Mar 2019 11:03:55 -0700	[thread overview]
Message-ID: <e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com> (raw)
In-Reply-To: <20190311224752.8337-1-valentin.schneider@arm.com>

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>    preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>    and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

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

WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
	<linux-kernel@vger.kernel.org>
Cc: uclinux-h8-devel@lists.sourceforge.jp,
	linux-xtensa@linux-xtensa.org, linux-ia64@vger.kernel.org,
	linux-c6x-dev@linux-c6x.org,
	Julien Thierry <julien.thierry@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-s390@vger.kernel.org, x86@kernel.org,
	linux-mips@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	Ingo Molnar <mingo@redhat.com>,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	nios2-dev@lists.rocketboards.org,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-snps-arc@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub
Date: Tue, 12 Mar 2019 11:03:55 -0700	[thread overview]
Message-ID: <e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com> (raw)
In-Reply-To: <20190311224752.8337-1-valentin.schneider@arm.com>

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>    preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>    and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

WARNING: multiple messages have this Message-ID (diff)
From: vineet.gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 00/14] entry: preempt_schedule_irq() callers scrub
Date: Tue, 12 Mar 2019 11:03:55 -0700	[thread overview]
Message-ID: <e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com> (raw)
In-Reply-To: <20190311224752.8337-1-valentin.schneider@arm.com>

On 3/11/19 3:47 PM, Valentin Schneider wrote:
> Hi,
> 
> This is the continuation of [1] where I'm hunting down
> preempt_schedule_irq() callers because of [2].
> 
> I told myself the best way to get this moving forward wouldn't be to write
> doc about it, but to go write some fixes and get some discussions going,
> which is what this patch-set is about.
> 
> I've looked at users of preempt_schedule_irq(), and made sure they didn't
> have one of those useless loops. The list of offenders is:
> 
> $ grep -r -I "preempt_schedule_irq" arch/ | cut -d/ -f2 | sort | uniq
> 
...

> 
> Regarding that loop, archs seem to fall in 3 categories:
> A) Those that don't have the loop

Please clarify that this is the right thing to do (since core code already has the
loop) hence no fixing is required for this "category"

> B) Those that have a small need_resched() loop around the
>    preempt_schedule_irq() callsite
> C) Those that branch to some more generic code further up the entry code
>    and eventually branch back to preempt_schedule_irq()
> 
> arc, m68k, nios2 fall in A)

> sparc, ia64, s390 fall in C)
> all the others fall in B)
> 
> I've written patches for B) and C) EXCEPT for ia64 and s390 because I
> haven't been able to tell if it's actually fine to kill that "long jump"
> (and maybe I'm wrong on sparc). Hopefully folks who understand what goes on
> in there might be able to shed some light.

  parent reply	other threads:[~2019-03-12 18:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 22:47 [PATCH 00/14] entry: preempt_schedule_irq() callers scrub Valentin Schneider
2019-03-11 22:47 ` Valentin Schneider
2019-03-11 22:47 ` Valentin Schneider
2019-03-11 22:47 ` Valentin Schneider
2019-03-11 22:47 ` [PATCH 01/14] sched/core: Fix preempt_schedule() interrupt return comment Valentin Schneider
2019-03-11 22:47 ` [PATCH 02/14] c6x: entry: Remove unneeded need_resched() loop Valentin Schneider
2019-03-13 17:21   ` Mark Salter
2019-03-11 22:47 ` [PATCH 03/14] csky: " Valentin Schneider
2019-03-11 22:47 ` [PATCH 04/14] h8300: " Valentin Schneider
2019-03-11 22:47 ` [PATCH 05/14] microblaze: " Valentin Schneider
2019-03-11 22:47 ` [PATCH 06/14] MIPS: " Valentin Schneider
2019-03-14 18:13   ` Paul Burton
2019-03-14 18:38     ` Valentin Schneider
2019-05-10 16:16     ` Maciej W. Rozycki
2019-03-15 16:31   ` [PATCH v2] " Valentin Schneider
2019-03-19 23:18     ` Paul Burton
2019-03-11 22:47 ` [PATCH 07/14] nds32: ex-exit: " Valentin Schneider
2019-04-24  7:18   ` Greentime Hu
2019-03-11 22:47 ` [PATCH 08/14] powerpc: entry: " Valentin Schneider
2019-03-11 22:47   ` Valentin Schneider
2019-05-03  6:59   ` Michael Ellerman
2019-05-03  6:59     ` Michael Ellerman
2019-03-11 22:47 ` [PATCH 09/14] RISC-V: " Valentin Schneider
2019-03-11 22:47   ` Valentin Schneider
2019-03-11 22:47 ` [PATCH 10/14] sh: " Valentin Schneider
2019-03-11 22:47 ` [PATCH 11/14] sh64: " Valentin Schneider
2019-03-11 22:47 ` [PATCH 12/14] sparc64: rtrap: " Valentin Schneider
2019-03-11 23:13   ` David Miller
2019-03-11 23:13     ` David Miller
2019-03-12  9:43     ` Valentin Schneider
2019-03-11 22:47 ` [PATCH 13/14] x86/entry: " Valentin Schneider
2019-04-05 13:13   ` [tip:x86/entry] " tip-bot for Valentin Schneider
2019-03-11 22:47 ` [PATCH 14/14] xtensa: entry: " Valentin Schneider
2019-03-12  1:10   ` Max Filippov
2019-03-12  9:45     ` Valentin Schneider
2019-03-12 18:03 ` Vineet Gupta [this message]
2019-03-12 18:03   ` [PATCH 00/14] entry: preempt_schedule_irq() callers scrub Vineet Gupta
2019-03-12 18:03   ` Vineet Gupta
2019-03-12 18:03   ` Vineet Gupta
2019-03-12 18:03   ` Vineet Gupta
2019-03-12 18:03   ` Vineet Gupta
2019-03-12 18:18   ` Valentin Schneider
2019-03-12 18:18     ` Valentin Schneider
2019-03-12 18:18     ` Valentin Schneider
2019-03-12 18:18     ` Valentin Schneider

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=e604601e-f8e1-a8b5-d364-69ca967996ce@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=julien.thierry@arm.com \
    --cc=linux-c6x-dev@linux-c6x.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=peterz@infradead.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=uclinux-h8-devel@lists.sourceforge.jp \
    --cc=valentin.schneider@arm.com \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.