From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751185AbbIBEvn (ORCPT ); Wed, 2 Sep 2015 00:51:43 -0400 Received: from mail-by2on0115.outbound.protection.outlook.com ([207.46.100.115]:57696 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750805AbbIBEvm (ORCPT ); Wed, 2 Sep 2015 00:51:42 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; Message-ID: <1441169492.4966.157.camel@freescale.com> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc From: Scott Wood 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" Date: Tue, 1 Sep 2015 23:51:32 -0500 In-Reply-To: References: <1441011520-15424-1-git-send-email-qiang.zhao@freescale.com> <1441153816.4966.109.camel@freescale.com> <1441160299.4966.122.camel@freescale.com> <1441161203.4966.126.camel@freescale.com> <1441163312.4966.145.camel@freescale.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.0-fta1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:448:8100:f9f:12bf:48ff:fe84:c9a0] X-ClientProxiedBy: CY1PR0601CA0015.namprd06.prod.outlook.com (25.160.162.25) To BLUPR03MB1474.namprd03.prod.outlook.com (25.163.81.16) X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1474;2:W2kMWeY+YOgrtMuOAP081gF+bVsoupX/bIfswsDsQ9jWCjpbVYarc/B3WKL/LxqxoKbrbuwHDLiFpQubCDHn1UpXFip6HeQEgyGi/+MEpxmqfaMCB5K2jDw6Cw+n13PrIYECW7icaVqlPr+bb0C/+VtOb2qKuzDBWYoVGYW0pQ0=;3:p9yFitMUY4YQVG5P04Frd1WSHoodjS9rZgnatC3SDq8jBS4YVBKEhZs2WFVdqAoDMwNw3Y9zitXKbE5Nipwnn2t2J1LJiyB9H4L45yuvVMD/FAtD/HnnRhdtzRGWMWFyndnc0M4ieiXmVdC4MCM+Pg==;25:ADenV1N5S4/DbLoSY4hH1pt/aZAoxbGCnRDcqYvBcD9C8igpUtfDSs9Aj5a0ENqDtkyqrxm937jbpj8MvLEaMwHm9DeKb8JIgmsEK8BZgZdXoeSn2MDJFjFosDMCRQ7yRlVCV3OSdEv//e2Luq39wwcCZwG0+4wOykN9/va27l71RN8Ub0Be+kWZOrPItqtK/664rBBeidVdfkiLejHawHyK4yr8z13XFc3We24J7G6yl0NfiSO51zlciqhx9jCn+ivG6iCjisAgZ+7XlcUfoQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1474; X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1474;20:UE0Klw0pXxnvLSklwqOAx18tOjRcFPZdp5ePjcD/Qhn1LL53NGTPgmY6YPH9FZ6eug75aOedtTtPEztsAOoWqScFukOS6xt8kwJTzW+Pq+b6lOea5YU6vl28eEKwECSMr2CH7/Zmf5Lx1AqP4nUgVaWp5em54jjmV6kXWvRPQwkWK6b/U4wiLy09P11mdaVAyVBolju3N9DZeJiXizIzN3k81GRlrWeMXLBCB7dHaIxB9qMzWSpoBtGAHIDWad/gXwhICrZGJhwFOvXchNq+lZVShSPZXDcrtD028zZSqRPQBs4sKNezBz+syYXCM+8av/JE1hNX9zwTjJvRwuwOzTVNxD0aySD+UrHKvLFQKsI1X912fjptrGGnix7FhOgfTXmncvg67AzGT2UXO1MpN07dHVYvCskfKXqVGIu6/yPrfMv90VgnCEIAbZdF4Cwu7ztVdEC5AxFG+iF8wbb6sRiz77A2C/12jZ3EJLGV/ORRCVJ4LuJi1Lq8kHur8887;4:ZfIYVpJ5q1I7GA4rpPEwlYfql2kILBH4iweV0k7jgTLvkT5d1eRo2husDRibN636Z8/l8+QFYiKo9iVqiYED8d1natF5Bg3LLIdqrr0vwbg3iqZNw87vscpi2PIjxXxaWtHUo2INPVA4MxAj9VW9qs8HnrUKdmIinZkQD8Unl5Jeb5RBhR+2HVem19Gw2i1fBATz8XjROT4dlIhwswU09ozoAy5o4qDtTeZZvWNtadRyrc35kNzW4SsmVcWJYOAWaact4OLeMQvmEzHK7iQqwCdR9s0gtpO433nuYWnkuBW+JxHMF2kWBQdB33qPN+HB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(8121501046)(5005006)(3002001);SRVR:BLUPR03MB1474;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1474; X-Forefront-PRVS: 0687389FB0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(377424004)(13464003)(54534003)(377454003)(199003)(189002)(50466002)(23676002)(50986999)(5001830100001)(5001860100001)(93886004)(19580395003)(189998001)(77096005)(4001540100001)(86362001)(5001960100002)(81156007)(50226001)(92566002)(5820100001)(36756003)(19580405001)(4001450100002)(33646002)(87976001)(42186005)(105586002)(110136002)(101416001)(97736004)(5004730100002)(122386002)(77156002)(106356001)(76176999)(68736005)(62966003)(64706001)(2950100001)(47776003)(46102003)(40100003)(103116003)(5007970100001)(99106002)(3826002)(5001840100002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR03MB1474;H:[IPv6:2601:448:8100:f9f:12bf:48ff:fe84:c9a0];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjAzTUIxNDc0OzIzOm5ZV25WTXFSYWZDaUxkUGVEaSs2SnpnOGVx?= =?utf-8?B?akRzM2oxRmR4LzJJQWZ5aFI5V3V1d0R2RHMwaXNadGFraWgxQ1ZhWHJPa1dj?= =?utf-8?B?TXhzUjM4VnFsZXFDeHFnazUwNEdZanRCVnREdVF5TTM0Y2NsVWc5YmFzYm80?= =?utf-8?B?a1NYV3ZYRGhOTnc0Vk1iVjVVbldORUR5ZlZEWEZwV1A0VVo1TUVsTXN3RElD?= =?utf-8?B?azRTNStRKzVVMSthRDhhaWlzVVJpMnExWlQyMGtUYXhHdlVFbzF0MUpTNDlu?= =?utf-8?B?NnNIOHYyTEd3SWRjWUkzK1kySmJKMlArZzI2YUFjcHZGa2RMc0ZHOC9ReGxP?= =?utf-8?B?OGdaQ0ZmN2VXK05UVUlWYitRaDBFNXVPVUhhV204UXVTRDBSc0o1WDQzelF0?= =?utf-8?B?dGxLNFFzT1ZYdmk1RWl3MThBOGIwQm01SVdtNzExZ2VUcExXR0VxYjZIOURi?= =?utf-8?B?dnN2aU1jbmZIMm1Ld2hhcDc1TDd2akV6dnJOdG9rQ1dSSzJYL3c0eDhhVGRU?= =?utf-8?B?QkRsVG12WTUydzUzY3ROS2dKai93ZlBGM1N1aDVZY09kRzBlVTRJUXlRcmUv?= =?utf-8?B?OWJnK0tPVjk4RjE4c1NhNDhZUDI1RDB5alc2TXVVRDFYTmh0a3JITCtNeVJu?= =?utf-8?B?RFNkaVdBODF6NzJ4TGs1U0xZYzArQmVDL2tMTitrekxCOFk3bEdMV0ZmQWYr?= =?utf-8?B?V01pempuSzQ0QllVVkl0WlM0OFZ4NGtEZEMybzFXYjhUbzZaTENmWnlNaEJ2?= =?utf-8?B?eWxOd2VBa2hxR29kcDE0clpZVmhBNVZCcWh1ZkF5TUVTQzBvWmF2a2Q5NE5J?= =?utf-8?B?NTRCc2p0Qk55UFlwN3ZobGkrTkRnWVBTaTRNbndiQ1MvcHpoOWh5dTlEU2Rs?= =?utf-8?B?NzlVbllnQUgwMFVSN0xVQzBpT1lKZ3RTeDFRZFdqZVlRYmdsZWYvR29LVzJJ?= =?utf-8?B?eHQyOUZoWDhqS2RnSlVJcDMzd3hWMmo4WUsvZ0lxakI4M1hDTEZENjBGeHNh?= =?utf-8?B?K1FFRnFtZEw2T0VVOHVwMkFGVDk0TnRrRHNTWG9RQ2lwWmJVaUpjUCt3ejlK?= =?utf-8?B?MFhSblcrb2xlNkx6UTJSS0lKWDdJY2VOQlAzMHRQUlNhMzBKSnAvcmNRbURW?= =?utf-8?B?RlhiKzM3NTVheVhRb1p6T09Lc0IxNHppSlQrSHgzRUZmZVdLRS81OWpvVUJs?= =?utf-8?B?UGZsbkFXYWxpNTlKMDZBckF3MTN0VWdtQTZKaEw0aGJsZ3B2aEl4SFlsVHRs?= =?utf-8?B?dW8xVnJTZGs1K3d2M0NscVV3VEJCUENUZzZSU3AxNnRCUkRWVW9QcEdyckNE?= =?utf-8?B?bG8vTWdBdU5iVXR3RFI3YitGS2JlSlZSdnp2OUY1Y2xrUCs2VFd5OWpuUUhl?= =?utf-8?B?dXUzWVV6djVBb2FOdEFNdmJzZU1YV21kTFZQdEtiQ0srbjkvejUvUHU2R3dE?= =?utf-8?B?RkV0cHpZMG9KbTFtY2JpTEFNYVB0MWYxTVdFZjExb0I2Sy9LUHpKbGMycG5J?= =?utf-8?B?dXRGUFZrZlE1UTVvaWIxNkJ2djBnMDNBTmVUaVpxMTBXaG9Fb2ZPWkNaWVJs?= =?utf-8?B?NTFhZXZ2S3dWaTNPRW9vV1hzczYydklkMk1HMFhSSXBGcm1zVVNYUHNKUE1t?= =?utf-8?B?YmRyV1dmcUk2R084enJOdkQyQ2tOajJhY2NFK1BSY0dFU1RoRGpQczBVSnRX?= =?utf-8?B?blhsS3A4ajYwb0ZZcFo2ck10Y25YQ3hYV2FlUHluTEtUQTVMbTBUU0VrRFdH?= =?utf-8?B?aDc2VDdSNXo4blVsSnQ5OU5DclFsanRrOUxnT3NxNk9pbkthWWhaTUtDTXVI?= =?utf-8?B?a3EwcjMrZjIyTEpEeXhEVUthcDJ6a1Z6RjJNWUhuQ3gvMEE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1474;5:79ARUU98jRabYtve/IEqLxxGnuMfleZnlAEQDbIk+jhsGZxniPqSudXLgLklU/J6IuBuF4+CAAVMRp83qaP9iUDRFV5nbj3jrzwcKpGiNe87oQfMP+FS+m2j/pAkzrkxeB0iWgboo4ZvUQ1cCluxGQ==;24:j9oW7dGuBxJgqnXRPQJIGxGYbv2hEQ/MOX2gDAMvuayxfH4wU3EC/ogrZoVFX6UiJ3EHBKoDReiHRLOv+ZaxlBoMcUAwAHqhDOO0yPgTPNA=;20:yWm8L1eWF933TiWZ+i0R1oASY4llEpaaPyEAoLNoYaOP2l8SWoMBI/hWFXb1D2dDPRWVwUr77mZClFBJKv1SUA== X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2015 04:51:38.7486 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1474 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-09-01 at 22:57 -0500, Zhao Qiang-B45475 wrote: > On Wed, 2015-09-02 at 10:33AM -0500, Wood Scott-B07421 wrote: > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Wednesday, September 02, 2015 11:09 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 22:05 -0500, Zhao Qiang-B45475 wrote: > > > 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 > > > > > > > > > --- > > > > > > > > > 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? > > > > I was thinking that it was a sufficiently different operation that it > > warranted its own independent function, but I suppose you could do it as > > an algorithm that only accepts the requested range and returns failure > > for all other chunks (as well as if the range is unavailable). It would > > not be related at all to the aligned-alloc algorithm. > > If do so, I need set algo in different muram_alloc function, it is > redundancy. If you do it as a separate top-level function there would be no algorithm. Using an algorithm would be simpler to implement, but a bit more awkward in the caller due to the need to swap out the algorithm (unless we change gen_pool_alloc_data to gen_pool_alloc_algo_data or similar...). > The algos has start para, but it set start_bit = 0 in gen_pool_alloc_data, > can We pass a start addr para to gen_pool_alloc_data? No. Again, setting that "start" variable is not equivalent to what you're trying to accomplish, even if it happens to work in your test case. -Scott