Messages in this thread |  | | Subject | Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc | From | Scott Wood <> | Date | Tue, 1 Sep 2015 21:33:23 -0500 |
| |
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?
> 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.
-Scott
|  |