On Fri, Nov 27, 2009 at 10:30 AM, Paul Mackerras wrote:
> Li Yang writes:
>
>> That's my concern too. But after all mmap without O_SYNC on I/O
>> devices should be deprecated.
>
> It should? Why?
>
> Shouldn't the onus rather be on those proposing an incompatible change
> to the kernel ABI, such
Li Yang writes:
> That's my concern too. But after all mmap without O_SYNC on I/O
> devices should be deprecated.
It should? Why?
Shouldn't the onus rather be on those proposing an incompatible change
to the kernel ABI, such as this is, to show why the change is
absolutely essential?
> A war
So what you are saying is that if the kernel has mapped a physical
page as cacheable while user application is trying to map it as
non-cacheable, there will be machine checks and checkstops rather than
just performance drop? This is new to me. Could you elaborate a bit?
If some data is in cach
On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert wrote:
> On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
>> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
>> wrote:
>> >>> You need to be a bit more careful tho. You must not allow RAM managed by
>> >>> the kernel to be mapped non-ca
On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
> wrote:
> >>> You need to be a bit more careful tho. You must not allow RAM managed by
> >>> the kernel to be mapped non-cachable.
> >>
> >> Even if the user explicitly sets the O_SYNC f
On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
wrote:
>>> You need to be a bit more careful tho. You must not allow RAM managed by
>>> the kernel to be mapped non-cachable.
>>
>> Even if the user explicitly sets the O_SYNC flag? IMHO, it's a bug of
>> the application if it uses O_SYNC on mai
You need to be a bit more careful tho. You must not allow RAM
managed by
the kernel to be mapped non-cachable.
Even if the user explicitly sets the O_SYNC flag? IMHO, it's a bug of
the application if it uses O_SYNC on main memory to be mmap'ed later.
And we don't need to cover up the bug.
I
On Fri, Nov 20, 2009 at 5:03 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2009-11-20 at 11:00 +0800, Li Yang-R58472 wrote:
>> Because there is no way to set mapped memory as cacheable if the
>> memory
>> is not managed by Linux kernel. While, it's not rare in real system
>> to
>> allocate some ded
On Fri, 2009-11-20 at 11:00 +0800, Li Yang-R58472 wrote:
> Because there is no way to set mapped memory as cacheable if the
> memory
> is not managed by Linux kernel. While, it's not rare in real system
> to
> allocate some dedicated memory to a certain application which is not
> managed by kernel
>-Original Message-
>From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>
>On Nov 17, 2009, at 1:10 AM, Li Yang wrote:
>
>> Rather than the original intelligent way, we grant user more freedom.
>> This enables user to map cacheable memory not managed by Linux.
>>
>> Signed-off-by: Li Y
On Nov 17, 2009, at 1:10 AM, Li Yang wrote:
Rather than the original intelligent way, we grant user more freedom.
This enables user to map cacheable memory not managed by Linux.
Signed-off-by: Li Yang
---
The only direct users of this function is fb_mmap() and /dev/mem mmap.
Although I'm not
Rather than the original intelligent way, we grant user more freedom.
This enables user to map cacheable memory not managed by Linux.
Signed-off-by: Li Yang
---
The only direct users of this function is fb_mmap() and /dev/mem mmap.
Although I'm not sure if anything is depending on the intelligent
12 matches
Mail list logo
