From: Kirill Tkhai <tkhai@yandex.ru>
To: David Miller <davem@davemloft.net>
Cc: allen.pais@oracle.com, linux-rt-users@vger.kernel.org,
sparclinux@vger.kernel.org, bigeasy@linutronix.de
Subject: Re: [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t
Date: Wed, 05 Mar 2014 00:44:05 +0400 [thread overview]
Message-ID: <53163B15.7060905@yandex.ru> (raw)
In-Reply-To: <20140304.145523.176895354551282596.davem@davemloft.net>
On 04.03.2014 23:55, David Miller wrote:
> From: Kirill Tkhai <tkhai@yandex.ru>
> Date: Wed, 12 Feb 2014 12:33:58 +0400
>
>> 12.02.2014, 11:48, "Allen Pais" <allen.pais@oracle.com>:
>>
>>> On Wednesday 12 February 2014 02:43 AM, Kirill Tkhai wrote:
>>>> 06.01.2014, 07:56, "Allen Pais" <allen.pais@oracle.com>:
>>>>> In the attempt of get PREEMPT_RT working on sparc64 using
>>>>> linux-stable-rt version 3.10.22-rt19+, the kernel crash
>>>>> with the following trace:
>>>>>
>>>>> [ 1487.027884] I7: <rt_mutex_setprio+0x3c/0x2c0>
>>>>> [ 1487.027885] Call Trace:
>>>>> [ 1487.027887] [00000000004967dc] rt_mutex_setprio+0x3c/0x2c0
>>>>> [ 1487.027892] [00000000004afe20] task_blocks_on_rt_mutex+0x180/0x200
>>>>> [ 1487.027895] [0000000000819114] rt_spin_lock_slowlock+0x94/0x300
>>>>> [ 1487.027897] [0000000000817ebc] __schedule+0x39c/0x53c
>>>>> [ 1487.027899] [00000000008185fc] schedule+0x1c/0xc0
>>>>> [ 1487.027908] [000000000048fff4] smpboot_thread_fn+0x154/0x2e0
>>>>> [ 1487.027913] [000000000048753c] kthread+0x7c/0xa0
>>>>> [ 1487.027920] [00000000004060c4] ret_from_syscall+0x1c/0x2c
>>>>> [ 1487.027922] [0000000000000000] (null)
>>> Now, consistently I've been getting sun4v_data_access_exception.
>>> Here's the trace:
>>> [ 4673.360121] sun4v_data_access_exception: ADDR[0000080000000000] CTX[0000] TYPE[0004], going.
>>
>> I've never dived at sparc's tlb before, but it seems now I'm understanding.
>>
>> arch_enter_lazy_mmu_mode() makes possible delayed tlb flushing. In !RT kernel
>> you collect flush requests before you really flush all of them.
>>
>> In RT you collect them too, but you are able to be preempted in any moment.
>> So, you may switch to other process with unflushed tlb, which is very bad.
>>
>> Try to not to set tb->active = 1; in arch_enter_lazy_mmu_mode(). Set it to zero.
>> We will look if this robust fix helps.
>
> Sorry for coming into this discussion so late.
>
> Indeed, the pending flushes are per-cpu and we must flush them out in the
> event of a preemption.
>
> PowerPC does the same exact thing with arch_enter_lazy_mmu_mode(), in
> fact that's where I copied the logic from. Does PowerPC not work with
> -rt? :-)
>
It does not work, but we will :)
WARNING: multiple messages have this Message-ID (diff)
From: Kirill Tkhai <tkhai@yandex.ru>
To: David Miller <davem@davemloft.net>
Cc: allen.pais@oracle.com, linux-rt-users@vger.kernel.org,
sparclinux@vger.kernel.org, bigeasy@linutronix.de
Subject: Re: [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t
Date: Tue, 04 Mar 2014 20:44:05 +0000 [thread overview]
Message-ID: <53163B15.7060905@yandex.ru> (raw)
In-Reply-To: <20140304.145523.176895354551282596.davem@davemloft.net>
On 04.03.2014 23:55, David Miller wrote:
> From: Kirill Tkhai <tkhai@yandex.ru>
> Date: Wed, 12 Feb 2014 12:33:58 +0400
>
>> 12.02.2014, 11:48, "Allen Pais" <allen.pais@oracle.com>:
>>
>>> On Wednesday 12 February 2014 02:43 AM, Kirill Tkhai wrote:
>>>> 06.01.2014, 07:56, "Allen Pais" <allen.pais@oracle.com>:
>>>>> In the attempt of get PREEMPT_RT working on sparc64 using
>>>>> linux-stable-rt version 3.10.22-rt19+, the kernel crash
>>>>> with the following trace:
>>>>>
>>>>> [ 1487.027884] I7: <rt_mutex_setprio+0x3c/0x2c0>
>>>>> [ 1487.027885] Call Trace:
>>>>> [ 1487.027887] [00000000004967dc] rt_mutex_setprio+0x3c/0x2c0
>>>>> [ 1487.027892] [00000000004afe20] task_blocks_on_rt_mutex+0x180/0x200
>>>>> [ 1487.027895] [0000000000819114] rt_spin_lock_slowlock+0x94/0x300
>>>>> [ 1487.027897] [0000000000817ebc] __schedule+0x39c/0x53c
>>>>> [ 1487.027899] [00000000008185fc] schedule+0x1c/0xc0
>>>>> [ 1487.027908] [000000000048fff4] smpboot_thread_fn+0x154/0x2e0
>>>>> [ 1487.027913] [000000000048753c] kthread+0x7c/0xa0
>>>>> [ 1487.027920] [00000000004060c4] ret_from_syscall+0x1c/0x2c
>>>>> [ 1487.027922] [0000000000000000] (null)
>>> Now, consistently I've been getting sun4v_data_access_exception.
>>> Here's the trace:
>>> [ 4673.360121] sun4v_data_access_exception: ADDR[0000080000000000] CTX[0000] TYPE[0004], going.
>>
>> I've never dived at sparc's tlb before, but it seems now I'm understanding.
>>
>> arch_enter_lazy_mmu_mode() makes possible delayed tlb flushing. In !RT kernel
>> you collect flush requests before you really flush all of them.
>>
>> In RT you collect them too, but you are able to be preempted in any moment.
>> So, you may switch to other process with unflushed tlb, which is very bad.
>>
>> Try to not to set tb->active = 1; in arch_enter_lazy_mmu_mode(). Set it to zero.
>> We will look if this robust fix helps.
>
> Sorry for coming into this discussion so late.
>
> Indeed, the pending flushes are per-cpu and we must flush them out in the
> event of a preemption.
>
> PowerPC does the same exact thing with arch_enter_lazy_mmu_mode(), in
> fact that's where I copied the logic from. Does PowerPC not work with
> -rt? :-)
>
It does not work, but we will :)
next prev parent reply other threads:[~2014-03-04 20:44 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 3:55 [PATCH 0/4] PREEMPT_RT support for sparc64 Allen Pais
2014-01-06 3:55 ` Allen Pais
2014-01-06 3:55 ` [PATCH 1/4] sparc64: use generic rwsem spinlocks rt Allen Pais
2014-01-06 3:56 ` Allen Pais
2014-01-06 3:55 ` [PATCH 2/4] sparc64: allow forced irq threading Allen Pais
2014-01-06 3:56 ` Allen Pais
2014-01-06 3:55 ` [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t Allen Pais
2014-01-06 3:56 ` Allen Pais
2014-02-11 21:13 ` Kirill Tkhai
2014-02-11 21:13 ` Kirill Tkhai
2014-02-12 7:31 ` Allen Pais
2014-02-12 7:43 ` Allen Pais
2014-02-12 7:48 ` Allen Pais
2014-02-12 7:48 ` Allen Pais
2014-02-12 8:33 ` Kirill Tkhai
2014-02-12 8:33 ` Kirill Tkhai
2014-02-12 11:28 ` Allen Pais
2014-02-12 11:40 ` Allen Pais
2014-02-12 11:43 ` Kirill Tkhai
2014-02-12 11:43 ` Kirill Tkhai
2014-02-12 12:14 ` Allen Pais
2014-02-12 12:26 ` Allen Pais
2014-02-12 12:45 ` Kirill Tkhai
2014-02-12 12:45 ` Kirill Tkhai
2014-02-12 13:05 ` Allen Pais
2014-02-12 13:17 ` Allen Pais
2014-02-19 3:53 ` Allen Pais
2014-02-19 3:54 ` Allen Pais
2014-02-19 8:09 ` Kirill Tkhai
2014-02-19 8:09 ` Kirill Tkhai
2014-02-19 8:12 ` Allen Pais
2014-02-19 8:24 ` Allen Pais
2014-02-19 8:57 ` Kirill Tkhai
2014-02-19 8:57 ` Kirill Tkhai
2014-02-19 8:59 ` Allen Pais
2014-02-19 8:59 ` Allen Pais
2014-02-19 9:13 ` Allen Pais
2014-02-19 9:25 ` Allen Pais
2014-02-19 9:25 ` Kirill Tkhai
2014-02-19 9:25 ` Kirill Tkhai
2014-02-19 9:31 ` Allen Pais
2014-02-19 9:43 ` Allen Pais
2014-02-26 7:51 ` Allen Pais
2014-02-26 7:52 ` Allen Pais
2014-02-28 14:51 ` Kirill Tkhai
2014-02-28 14:51 ` Kirill Tkhai
2014-03-04 19:10 ` David Miller
2014-03-04 19:10 ` David Miller
2014-03-04 20:28 ` David Miller
2014-03-04 20:28 ` David Miller
2014-03-05 4:30 ` Allen Pais
2014-03-05 4:42 ` Allen Pais
2014-03-06 21:36 ` David Miller
2014-03-06 21:36 ` David Miller
2014-03-07 14:05 ` Sebastian Andrzej Siewior
2014-03-07 14:05 ` Sebastian Andrzej Siewior
2014-03-04 20:39 ` Kirill Tkhai
2014-03-04 20:39 ` Kirill Tkhai
2014-03-07 13:41 ` Sebastian Andrzej Siewior
2014-03-07 13:41 ` Sebastian Andrzej Siewior
2014-03-04 20:03 ` David Miller
2014-03-04 20:03 ` David Miller
2014-03-04 21:26 ` Kirill Tkhai
2014-03-04 21:26 ` Kirill Tkhai
2014-03-04 20:01 ` David Miller
2014-03-04 20:01 ` David Miller
2014-03-05 4:34 ` Allen Pais
2014-03-05 4:46 ` Allen Pais
2014-03-05 4:52 ` David Miller
2014-03-05 4:52 ` David Miller
2014-03-04 19:59 ` David Miller
2014-03-04 19:59 ` David Miller
2014-03-04 19:55 ` David Miller
2014-03-04 19:55 ` David Miller
2014-03-04 20:44 ` Kirill Tkhai [this message]
2014-03-04 20:44 ` Kirill Tkhai
2014-03-07 14:29 ` Sebastian Andrzej Siewior
2014-03-07 14:29 ` Sebastian Andrzej Siewior
2014-01-06 3:55 ` [PATCH 4/4] sparc64: convert ctx_alloc_lock raw_spinlock_t Allen Pais
2014-01-06 3:56 ` Allen Pais
2014-02-05 3:31 ` [PATCH 0/4] PREEMPT_RT support for sparc64 Allen Pais
2014-02-05 8:28 ` Sebastian Andrzej Siewior
2014-02-05 10:38 ` Allen Pais
2014-02-05 10:43 ` Sebastian Andrzej Siewior
2014-02-05 10:51 ` Allen Pais
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=53163B15.7060905@yandex.ru \
--to=tkhai@yandex.ru \
--cc=allen.pais@oracle.com \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=linux-rt-users@vger.kernel.org \
--cc=sparclinux@vger.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.