On Wed, May 25, 2016 at 06:27:07PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote:
> > That's when we realised that the CoW problem no longer exists for
> > non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178
> > has not
On Wed, May 25, 2016 at 06:27:07PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote:
> > That's when we realised that the CoW problem no longer exists for
> > non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178
> > has not
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/25 18:50, Catalin Marinas wrote:
> > What happens is that __sync_icache_dcache() only takes care of the first
> > time a page is mapped in user space and flushes the caches, marking it
> > as "clean"
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/25 18:50, Catalin Marinas wrote:
> > What happens is that __sync_icache_dcache() only takes care of the first
> > time a page is mapped in user space and flushes the caches, marking it
> > as "clean"
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote:
> Hi,
> As my tracing, it is returned by "if (!page_mapping(page))", because "mmap"
> are anonymous pages. I commented below code lines, it works well.
>
> /* no flushing needed for anonymous pages */
> if
On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote:
> Hi,
> As my tracing, it is returned by "if (!page_mapping(page))", because "mmap"
> are anonymous pages. I commented below code lines, it works well.
>
> /* no flushing needed for anonymous pages */
> if
On 2016/5/25 18:50, Catalin Marinas wrote:
> On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
>>> On 2016/5/24 21:02, Catalin Marinas wrote:
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>
On 2016/5/25 18:50, Catalin Marinas wrote:
> On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
>>> On 2016/5/24 21:02, Catalin Marinas wrote:
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>
On 2016/5/25 18:50, Catalin Marinas wrote:
> On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
>>> On 2016/5/24 21:02, Catalin Marinas wrote:
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>
On 2016/5/25 18:50, Catalin Marinas wrote:
> On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
>>> On 2016/5/24 21:02, Catalin Marinas wrote:
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>
On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote:
> That's when we realised that the CoW problem no longer exists for
> non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178
> has not been reverted.
I think I mostly agree, except for reverting 6060e8df5178, which
On Wed, May 25, 2016 at 04:22:55PM +0100, Catalin Marinas wrote:
> That's when we realised that the CoW problem no longer exists for
> non-aliasing VIPT caches. However, the I-cache counterpart 6060e8df5178
> has not been reverted.
I think I mostly agree, except for reverting 6060e8df5178, which
On Tue, May 24, 2016 at 04:12:35PM +0100, Mark Rutland wrote:
> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> > On 2016/5/24 19:37, Mark Rutland wrote:
> > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> > >> When we ran mprotect04(a test case in LTP)
On Tue, May 24, 2016 at 04:12:35PM +0100, Mark Rutland wrote:
> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> > On 2016/5/24 19:37, Mark Rutland wrote:
> > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> > >> When we ran mprotect04(a test case in LTP)
On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
> > On 2016/5/24 21:02, Catalin Marinas wrote:
> >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> >>> On 2016/5/24 19:37, Mark Rutland wrote:
>
On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
> > On 2016/5/24 21:02, Catalin Marinas wrote:
> >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> >>> On 2016/5/24 19:37, Mark Rutland wrote:
>
On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
>
>
> On 2016/5/24 21:02, Catalin Marinas wrote:
>> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>>> On 2016/5/24 19:37, Mark Rutland wrote:
On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> When we
On 2016/5/25 9:20, Leizhen (ThunderTown) wrote:
>
>
> On 2016/5/24 21:02, Catalin Marinas wrote:
>> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>>> On 2016/5/24 19:37, Mark Rutland wrote:
On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> When we
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2016/5/24 19:37, Mark Rutland wrote:
> > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> >> When we ran mprotect04(a test case in LTP) infinitely, it would always
> >> failed after a few seconds. The case
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2016/5/24 19:37, Mark Rutland wrote:
> > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> >> When we ran mprotect04(a test case in LTP) infinitely, it would always
> >> failed after a few seconds. The case
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/24 19:37, Mark Rutland wrote:
> > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> >> When we ran mprotect04(a test case in LTP) infinitely, it would always
> >> failed after a few seconds. The case can
On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote:
> On 2016/5/24 19:37, Mark Rutland wrote:
> > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> >> When we ran mprotect04(a test case in LTP) infinitely, it would always
> >> failed after a few seconds. The case can
On 2016/5/24 19:37, Mark Rutland wrote:
> On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
>> When we ran mprotect04(a test case in LTP) infinitely, it would always
>> failed after a few seconds. The case can be described briefly that: copy
>> a empty function from code area into a new
On 2016/5/24 19:37, Mark Rutland wrote:
> On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
>> When we ran mprotect04(a test case in LTP) infinitely, it would always
>> failed after a few seconds. The case can be described briefly that: copy
>> a empty function from code area into a new
On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> When we ran mprotect04(a test case in LTP) infinitely, it would always
> failed after a few seconds. The case can be described briefly that: copy
> a empty function from code area into a new memory area(created by mmap),
> then call
On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote:
> When we ran mprotect04(a test case in LTP) infinitely, it would always
> failed after a few seconds. The case can be described briefly that: copy
> a empty function from code area into a new memory area(created by mmap),
> then call
When we ran mprotect04(a test case in LTP) infinitely, it would always
failed after a few seconds. The case can be described briefly that: copy
a empty function from code area into a new memory area(created by mmap),
then call mprotect to change the protection to PROT_EXEC. The syscall
When we ran mprotect04(a test case in LTP) infinitely, it would always
failed after a few seconds. The case can be described briefly that: copy
a empty function from code area into a new memory area(created by mmap),
then call mprotect to change the protection to PROT_EXEC. The syscall
28 matches
Mail list logo