[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A54FFFE.10306@petalogix.com>
Date: Wed, 08 Jul 2009 22:22:22 +0200
From: Michal Simek <michal.simek@...alogix.com>
To: David Miller <davem@...emloft.net>
CC: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
mingo@...e.hu, arnd@...db.de, lethal@...ux-sh.org,
ltp-list@...ts.sourceforge.net
Subject: Re: mmap hw behavior
David Miller wrote:
> From: Michal Simek <michal.simek@...alogix.com>
> Date: Wed, 08 Jul 2009 20:03:27 +0200
>
>
>> David Miller wrote:
>>
>>> From: Michal Simek <michal.simek@...alogix.com>
>>> Date: Wed, 08 Jul 2009 19:03:11 +0200
>>>
>>>
>>>
>>>> When I call mmap for that open file with pointer to calloc place
>>>> (first parameter, + length zero) it should be one tlb invalidation
>>>> for calloc and new tlb which connect open file. We check it and we
>>>> don't have any tlb invalidation that's why I think that kernel do
>>>> different thigs. Or is it there any copying? Or anything different?
>>>>
>>>>
>>> There is no need to tlb flush the calloc area unless that memory area
>>> is actually touched by the user application and thus the page is
>>> faulted in.
>>>
>>>
>> That calloc area is filled by any value (in that test). Is it mean that
>> for this case when calloc area is touched
>> there must be tlb invalidation + remapping?
>>
>
> Yes, if the calloc area is written to by the application, there
> should be a tlb flush when the mmap() overrides that virtual region
> with a different mapping.
>
Can you please point me to any code which exactly do this? (for example
file mm/mmap.c line from ... to ... )
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists