From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/5] ARM: add support for kernel mode NEON
Date: Fri, 28 Jun 2013 16:46:22 +0100 [thread overview]
Message-ID: <20130628154622.GF1643@arm.com> (raw)
In-Reply-To: <CAKv+Gu92+pMLF9FPwbrkVLLhnPdBB702PXG-F2-3kqZx60TEHg@mail.gmail.com>
On Fri, Jun 28, 2013 at 03:00:02PM +0100, Ard Biesheuvel wrote:
> On 28 June 2013 15:46, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 12:55 Wed 26 Jun , Ard Biesheuvel wrote:
> >> Meh. This is not going to please the RT crowd, as preempt_schedule()
> >> will not be called on PREEMPT builds in this case.
> >>
> >> Propose to replace it with
> >>
> >> preempt_enable();
> >> #ifndef CONFIG_PREEMPT_COUNT
> > if (IS_ENABLED(CONFIG_xxx)) at least
> >> /* in this case, the preempt_enable() right above is just a barrier() */
> >> dec_preempt_count();
> >> #endif
> >
> > but why do you need to call inc_preempt and dec directly?
>
> There is a concern that violations of the rule that a task should not
> sleep between kernel_neon_begin and kernel_neon_end calls may not be
> spotted on non-PREEMPT builds that don't have
> CONFIG_DEBUG_ATOMIC_SLEEP set.
Would an explicit call to schedule() trigger with
CONFIG_DEBUG_ATOMIC_SLEEP? It looks that this config option only
triggers for explicit might_sleep() calls but we don't have one for
explicit schedule() calls (cond_resched() call has might_sleep()).
--
Catalin
next prev parent reply other threads:[~2013-06-28 15:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 20:24 [PATCH v2 0/5] kernel mode NEON support Ard Biesheuvel
2013-06-25 20:24 ` [PATCH v2 1/5] ARM: move VFP init to an earlier boot stage Ard Biesheuvel
2013-06-25 20:24 ` [PATCH v2 2/5] ARM: be strict about FP exceptions in kernel mode Ard Biesheuvel
2013-06-25 20:24 ` [PATCH v2 3/5] ARM: add support for kernel mode NEON Ard Biesheuvel
2013-06-26 10:55 ` Ard Biesheuvel
2013-06-26 11:14 ` Will Deacon
2013-06-26 11:28 ` Ard Biesheuvel
2013-06-26 12:40 ` Will Deacon
2013-06-26 12:52 ` Ard Biesheuvel
2013-06-26 13:13 ` Ard Biesheuvel
2013-06-27 13:11 ` Ard Biesheuvel
2013-06-27 15:09 ` Will Deacon
2013-06-27 15:13 ` Catalin Marinas
2013-06-27 15:43 ` Ard Biesheuvel
2013-06-28 10:25 ` Ard Biesheuvel
2013-06-28 13:46 ` Jean-Christophe PLAGNIOL-VILLARD
2013-06-28 14:00 ` Ard Biesheuvel
2013-06-28 15:46 ` Catalin Marinas [this message]
2013-06-28 20:17 ` Ard Biesheuvel
2013-06-25 20:24 ` [PATCH v2 4/5] ARM: crypto: add NEON accelerated XOR implementation Ard Biesheuvel
2013-06-25 20:24 ` [PATCH v2 5/5] lib/raid6: add ARM-NEON accelerated syndrome calculation Ard Biesheuvel
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=20130628154622.GF1643@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.