linux-mips
[Top] [All Lists]

Re: patch to support topdown mmap allocation in MIPS

To: "Kevin Cernekee" <cernekee@gmail.com>
Subject: Re: patch to support topdown mmap allocation in MIPS
From: "Jian Peng" <jipeng@broadcom.com>
Date: Mon, 16 May 2011 21:04:53 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "David Daney" <ddaney@caviumnetworks.com>, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>, "Ralf Baechle" <ralf@linux-mips.org>
In-reply-to: <BANLkTikq04wuK=bz+Lieavmm3oDtoYWKxg@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E18F441196CA634DB8E1F1C56A50A8743242B54C8A@IRVEXCHCCR01.corp.ad.broadcom.com> <4DD1BD72.2000408@caviumnetworks.com> <BANLkTikq04wuK=bz+Lieavmm3oDtoYWKxg@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcwUR5bBt8/u3D2oTGCKecpzeVAkkw==
Thread-topic: patch to support topdown mmap allocation in MIPS
Good points. I cannot access working system now and will investigate it further 
tomorrow.

On May 16, 2011, at 6:27 PM, "Kevin Cernekee" <cernekee@gmail.com> wrote:

> On Mon, May 16, 2011 at 5:12 PM, David Daney <ddaney@caviumnetworks.com> 
> wrote:
>> On 05/16/2011 02:09 PM, Jian Peng wrote:
>>>  #define COLOUR_ALIGN(addr,pgoff)                              \
>>>        ((((addr) + shm_align_mask)&  ~shm_align_mask) +        \
>>>         (((pgoff)<<  PAGE_SHIFT)&  shm_align_mask))
> 
> I see COLOUR_ALIGN in arch/{arm,mips,sh,sparc} .  All sorts of
> embedded platforms have to worry about cache aliases nowadays.
> 
> Do you think this logic could be folded into the generic
> implementations in mm/mmap.c ?  Or is there something else inside our
> arch_get_unmapped_area* functions that's really, irreparably unique to
> MIPS?
> 
>>> +#ifdef CONFIG_32BIT
>>> +       task_size = TASK_SIZE;
>>> +#else /* Must be CONFIG_64BIT*/
>>> +       task_size = test_thread_flag(TIF_32BIT_ADDR) ? TASK_SIZE32 :
>>> TASK_SIZE;
>>> +#endif
> 
> Can the "#else" clause and "task_size" local variable be eliminated?
> TASK_SIZE now performs this check automatically (although that wasn't
> always the case).
> 


<Prev in Thread] Current Thread [Next in Thread>