All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@paralogos.com>
To: linux-mips@linux-mips.org
Subject: Re: 1004K MT paging issue
Date: Mon, 26 May 2014 15:57:33 -0700	[thread overview]
Message-ID: <5383C6DD.4090107@paralogos.com> (raw)
In-Reply-To: <498838AF-48B0-4244-95C0-F590040E5E08@axis.com>

When a VPE hits an exception and sets EXL, thread scheduling stops and
the VPE is single-threaded coming into the exception.  With dual VPEs,
one of them hitting a fault won't prevent another from doing so, but all
the usual rules of locking and ordering that are needed for any SMP
kernel should apply and "just work".  Is there any SMP support in the VM
subsystem that's conditionally modfied or excluded for your 1004K kernel
build?

/K.


On 5/26/2014 1:56 PM, Mikael Starvik wrote:
> Hi!
>
> We have a 1004K core with two VPEs with two TCs per VPE. We have a problem that is hard to debug and would like to know if anyone has seen or solved such an issue.
>
> A multithreaded application is running. 
> Twoapplication threads are running in one TC each on the same VPE.
> A piece of code has been paged out.
> Application thread 1 tries to execute the code and thus gets a page fault.
> While the page fault is being handled the second application thread enters the same code.
> For some reason it looks like application thread 2 is allowed to execute even if the page fault handling has not been finished yet.
> Thread 2 executes the wrong code and typically gets a reserved instruction exception.
>
> Any thougts?
>
> BR
> /Mikael

  reply	other threads:[~2014-05-26 22:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-26 20:56 1004K MT paging issue Mikael Starvik
2014-05-26 20:56 ` Mikael Starvik
2014-05-26 22:57 ` Kevin D. Kissell [this message]
2014-05-27 11:11 ` Lars Persson

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=5383C6DD.4090107@paralogos.com \
    --to=kevink@paralogos.com \
    --cc=linux-mips@linux-mips.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.