lkml.org 
[lkml]   [2015]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
Date
On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote:

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 02, 2015 10:33 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li
> Yang-Leo-R58472; paulus@samba.org
> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
>
> On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote:
> > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote:
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 02, 2015 10:18 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@samba.org
> > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with
> > > bytes-alignment to genalloc
> > >
> > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 02, 2015 8:30 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061;
> > > > > benh@kernel.crashing.org; Li Yang-Leo-R58472; paulus@samba.org
> > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation
> > > > > with bytes-alignment to genalloc
> > > > >
> > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote:
> > > > > > Bytes alignment is required to manage some special RAM, so add
> > > > > > gen_pool_first_fit_align to genalloc, meanwhile add
> > > > > > gen_pool_alloc_data to pass data to
> > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
> > > > > >
> > > > > > Signed-off-by: Zhao Qiang <qiang.zhao@freescale.com>
> > > > > > ---
> > > > > > Changes for v6:
> > > > > > - patches set v6 include a new patch because of using
> > > > > > - genalloc to manage QE MURAM, patch 0001 is the new
> > > > > > - patch, adding bytes alignment for allocation for use.
> > > > > > Changes for v7:
> > > > > > - cpm muram also need to use genalloc to manage, it has
> > > > > > a function to reserve a specific region of muram,
> > > > > > add offset to genpool_data for start addr to be
> allocated.
> > > > >
> > > > > This seems to be describing more than just the changes in this
> patch.
> > > > > What does also handling cpm have to do with this patch? Are you
> > > > > adding support for reserving a specific region in this patch? I
> > > > > don't see it, and in any case it should go in a different patch.
> > > >
> > > > Yes, I added. The code below can support the function.
> > > > offset_bit = (alignment->offset + (1UL << order) - 1) >>
> order;
> > > > return bitmap_find_next_zero_area(map, size, start +
> > > > offset_bit,
> > > nr,
> > > > align_mask);
> > > >
> > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate
> > > > muram from a Specific offset. So I add the code and add offset to
> struct data.
> > >
> > > I thought the offset was related to the previous discussion of
> > > checking for allocation failure. Are you using it to implement
> > > alloc_fixed()? If so, please don't. Besides the awkward
> > > implementation (what does it logically have to do with
> > > gen_pool_first_fit_align?), it does not appear to be correct -
> > > - what happens with multiple chunks? What happens if part of the
> > > region the caller is trying to reserve is already taken? Implement
> > > a proper function to reserve a fixed genalloc region.
> >
> > This offset is totally different with the workaround OFFSET!
>
> There's a reason why we write changelogs that describe what the patch is
> doing, and avoid combining logically distinct changes in the same patch.
>
> > This offset is the offset of the muram.
>
> The offset of the muram relative to what? Or do you mean the offset into
> muram?

Yes, the offset into muram.

>
> > CPM need to allocate block from a specific offset due to hardware
> > restriction.
> > So I must handle this offset in genalloc.
>
> Again, if you need to be able to mark a specific range reserved, add a
> function that does that properly. Don't try to hack it in the way you
> did.

Add a function? Do you mean add a new alloc function or new algo?
If you mean new algo, CPM use both align algo and new algo, set
Different algos in different muram_alloc func?

>
> -Scott

\
 
 \ /
  Last update: 2015-09-02 05:21    [W:0.273 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site