* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs @ 2017-04-30 14:36 Shanker Donthineni 2017-05-02 16:16 ` Marc Zyngier 0 siblings, 1 reply; 6+ messages in thread From: Shanker Donthineni @ 2017-04-30 14:36 UTC (permalink / raw) To: linux-arm-kernel We are always allocating extra 255Bytes of memory to handle ITE physical address alignment requirement. The kmalloc() satisfies the ITE alignment since the ITS driver is requesting a minimum size of ITS_ITT_ALIGN bytes. Let's try to allocate the exact amount of memory that is required for ITEs to avoid wastage. Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> --- Changes: v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit. v3: changed from IITE to ITE. v3: removed fallback since kmalloc() guarantees the right alignment. drivers/irqchip/irq-gic-v3-its.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 45ea1933..72e56f03 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd, u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN); its_encode_cmd(cmd, GITS_CMD_MAPD); its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id); @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, */ nr_ites = max(2UL, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; + sz = max(sz, ITS_ITT_ALIGN); itt = kzalloc(sz, GFP_KERNEL); lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis); if (lpi_map) col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL); - if (!dev || !itt || !lpi_map || !col_map) { + if (!dev || !itt || !lpi_map || !col_map || + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) { kfree(dev); kfree(itt); kfree(lpi_map); -- Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs 2017-04-30 14:36 [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs Shanker Donthineni @ 2017-05-02 16:16 ` Marc Zyngier 2017-05-05 22:04 ` Shanker Donthineni 0 siblings, 1 reply; 6+ messages in thread From: Marc Zyngier @ 2017-05-02 16:16 UTC (permalink / raw) To: linux-arm-kernel On Sun, Apr 30 2017 at 3:36:15 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: > We are always allocating extra 255Bytes of memory to handle ITE > physical address alignment requirement. The kmalloc() satisfies > the ITE alignment since the ITS driver is requesting a minimum > size of ITS_ITT_ALIGN bytes. > > Let's try to allocate the exact amount of memory that is required > for ITEs to avoid wastage. > > Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> > --- > Changes: > v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit. > v3: changed from IITE to ITE. > v3: removed fallback since kmalloc() guarantees the right alignment. > > drivers/irqchip/irq-gic-v3-its.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 45ea1933..72e56f03 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd, > u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); > > itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); > - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN); > > its_encode_cmd(cmd, GITS_CMD_MAPD); > its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id); > @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, > */ > nr_ites = max(2UL, roundup_pow_of_two(nvecs)); > sz = nr_ites * its->ite_size; > - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; > + sz = max(sz, ITS_ITT_ALIGN); > itt = kzalloc(sz, GFP_KERNEL); > lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis); > if (lpi_map) > col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL); > > - if (!dev || !itt || !lpi_map || !col_map) { > + if (!dev || !itt || !lpi_map || !col_map || > + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) { > kfree(dev); > kfree(itt); > kfree(lpi_map); I'm confused. Either the alignment is guaranteed (and you should document why it is so), or it is not, and we need to handle the non-alignment (instead of failing). Thanks, M. -- Jazz is not dead, it just smell funny. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs 2017-05-02 16:16 ` Marc Zyngier @ 2017-05-05 22:04 ` Shanker Donthineni 2017-05-06 11:25 ` Marc Zyngier 0 siblings, 1 reply; 6+ messages in thread From: Shanker Donthineni @ 2017-05-05 22:04 UTC (permalink / raw) To: linux-arm-kernel Hi Marc, On 05/02/2017 11:16 AM, Marc Zyngier wrote: > On Sun, Apr 30 2017 at 3:36:15 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: >> We are always allocating extra 255Bytes of memory to handle ITE >> physical address alignment requirement. The kmalloc() satisfies >> the ITE alignment since the ITS driver is requesting a minimum >> size of ITS_ITT_ALIGN bytes. >> >> Let's try to allocate the exact amount of memory that is required >> for ITEs to avoid wastage. >> >> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> >> --- >> Changes: >> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit. >> v3: changed from IITE to ITE. >> v3: removed fallback since kmalloc() guarantees the right alignment. >> >> drivers/irqchip/irq-gic-v3-its.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >> index 45ea1933..72e56f03 100644 >> --- a/drivers/irqchip/irq-gic-v3-its.c >> +++ b/drivers/irqchip/irq-gic-v3-its.c >> @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd, >> u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); >> >> itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); >> - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN); >> >> its_encode_cmd(cmd, GITS_CMD_MAPD); >> its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id); >> @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, >> */ >> nr_ites = max(2UL, roundup_pow_of_two(nvecs)); >> sz = nr_ites * its->ite_size; >> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; >> + sz = max(sz, ITS_ITT_ALIGN); >> itt = kzalloc(sz, GFP_KERNEL); >> lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis); >> if (lpi_map) >> col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL); >> >> - if (!dev || !itt || !lpi_map || !col_map) { >> + if (!dev || !itt || !lpi_map || !col_map || >> + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) { >> kfree(dev); >> kfree(itt); >> kfree(lpi_map); > I'm confused. Either the alignment is guaranteed (and you should > document why it is so), or it is not, and we need to handle the > non-alignment (instead of failing). Sorry for confusion, alignment is guaranteed by kmalloc(), added a check for readability purpose only can be removed. > Thanks, > > M. -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs 2017-05-05 22:04 ` Shanker Donthineni @ 2017-05-06 11:25 ` Marc Zyngier 2017-06-21 1:22 ` Shanker Donthineni 0 siblings, 1 reply; 6+ messages in thread From: Marc Zyngier @ 2017-05-06 11:25 UTC (permalink / raw) To: linux-arm-kernel On Fri, May 05 2017 at 11:04:22 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: > Hi Marc, > > > On 05/02/2017 11:16 AM, Marc Zyngier wrote: >> On Sun, Apr 30 2017 at 3:36:15 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: >>> We are always allocating extra 255Bytes of memory to handle ITE >>> physical address alignment requirement. The kmalloc() satisfies >>> the ITE alignment since the ITS driver is requesting a minimum >>> size of ITS_ITT_ALIGN bytes. >>> >>> Let's try to allocate the exact amount of memory that is required >>> for ITEs to avoid wastage. >>> >>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> >>> --- >>> Changes: >>> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit. >>> v3: changed from IITE to ITE. >>> v3: removed fallback since kmalloc() guarantees the right alignment. >>> >>> drivers/irqchip/irq-gic-v3-its.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >>> index 45ea1933..72e56f03 100644 >>> --- a/drivers/irqchip/irq-gic-v3-its.c >>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>> @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd, >>> u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); >>> >>> itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); >>> - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN); >>> >>> its_encode_cmd(cmd, GITS_CMD_MAPD); >>> its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id); >>> @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, >>> */ >>> nr_ites = max(2UL, roundup_pow_of_two(nvecs)); >>> sz = nr_ites * its->ite_size; >>> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; >>> + sz = max(sz, ITS_ITT_ALIGN); >>> itt = kzalloc(sz, GFP_KERNEL); >>> lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis); >>> if (lpi_map) >>> col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL); >>> >>> - if (!dev || !itt || !lpi_map || !col_map) { >>> + if (!dev || !itt || !lpi_map || !col_map || >>> + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) { >>> kfree(dev); >>> kfree(itt); >>> kfree(lpi_map); >> I'm confused. Either the alignment is guaranteed (and you should >> document why it is so), or it is not, and we need to handle the >> non-alignment (instead of failing). > > Sorry for confusion, alignment is guaranteed by kmalloc(), added a > check for readability purpose only can be removed. My question still remains. Where exactly is that alignment guarantee documented and enforced? I can't see anything giving that certainty. I would expect kmalloc to give you something that is cache-line aligned, but probably nothing more than that. Now, I'd happily be proven wrong, but so far, all I can see is that: - ARCH_KMALLOC_MINALIGN is defined as ARCH_DMA_MINALIGN - ARCH_DMA_MINALIGN is defined as L1_CACHE_BYTES - L1_CACHE_BYTES is 128 on arm64, and either 32, 64, or 128 on arm. What am I missing? Thanks, M. -- Jazz is not dead, it just smell funny. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs 2017-05-06 11:25 ` Marc Zyngier @ 2017-06-21 1:22 ` Shanker Donthineni 2017-06-21 7:30 ` Marc Zyngier 0 siblings, 1 reply; 6+ messages in thread From: Shanker Donthineni @ 2017-06-21 1:22 UTC (permalink / raw) To: linux-arm-kernel Hi Marc, On 05/06/2017 06:25 AM, Marc Zyngier wrote: > On Fri, May 05 2017 at 11:04:22 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: >> Hi Marc, >> >> >> On 05/02/2017 11:16 AM, Marc Zyngier wrote: >>> On Sun, Apr 30 2017 at 3:36:15 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: >>>> We are always allocating extra 255Bytes of memory to handle ITE >>>> physical address alignment requirement. The kmalloc() satisfies >>>> the ITE alignment since the ITS driver is requesting a minimum >>>> size of ITS_ITT_ALIGN bytes. >>>> >>>> Let's try to allocate the exact amount of memory that is required >>>> for ITEs to avoid wastage. >>>> >>>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> >>>> --- >>>> Changes: >>>> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit. >>>> v3: changed from IITE to ITE. >>>> v3: removed fallback since kmalloc() guarantees the right alignment. >>>> >>>> drivers/irqchip/irq-gic-v3-its.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >>>> index 45ea1933..72e56f03 100644 >>>> --- a/drivers/irqchip/irq-gic-v3-its.c >>>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>>> @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd, >>>> u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); >>>> >>>> itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); >>>> - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN); >>>> >>>> its_encode_cmd(cmd, GITS_CMD_MAPD); >>>> its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id); >>>> @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, >>>> */ >>>> nr_ites = max(2UL, roundup_pow_of_two(nvecs)); >>>> sz = nr_ites * its->ite_size; >>>> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; >>>> + sz = max(sz, ITS_ITT_ALIGN); >>>> itt = kzalloc(sz, GFP_KERNEL); >>>> lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis); >>>> if (lpi_map) >>>> col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL); >>>> >>>> - if (!dev || !itt || !lpi_map || !col_map) { >>>> + if (!dev || !itt || !lpi_map || !col_map || >>>> + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) { >>>> kfree(dev); >>>> kfree(itt); >>>> kfree(lpi_map); >>> I'm confused. Either the alignment is guaranteed (and you should >>> document why it is so), or it is not, and we need to handle the >>> non-alignment (instead of failing). >> >> Sorry for confusion, alignment is guaranteed by kmalloc(), added a >> check for readability purpose only can be removed. > > My question still remains. Where exactly is that alignment guarantee > documented and enforced? I can't see anything giving that certainty. > The internal implementation of kmalloc() uses the slab/slub feature to allocate memory from 2^N size pool. Linux kernel maintains the fixed size of kmem_cache pools to serve the kmalloc(), It allocates minimum size of 128Bytes and maximum size depends on the system configuration and memory availability. In fact SMMUv3 driver has a similar requirement and absolutely there no problem using kmalloc() to meet the address alignment requirement. Call trace: kmalloc() kmalloc_slab() --> convert size to kmem_cache slab_alloc() ---> allocate 2^N size kmem_cache object root at null-8cfdf006971f:~# cat /proc/slabinfo | grep kmall dma-kmalloc-131072 0 0 131072 4 8 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-65536 0 0 65536 8 8 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-32768 0 0 32768 16 8 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-16384 0 0 16384 32 8 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-8192 0 0 8192 32 4 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-4096 0 0 4096 32 2 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-2048 0 0 2048 32 1 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-1024 0 0 1024 64 1 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-512 128 128 512 128 1 : tunables 0 0 0 : slabdata 1 1 0 dma-kmalloc-256 0 0 256 256 1 : tunables 0 0 0 : slabdata 0 0 0 dma-kmalloc-128 512 512 128 512 1 : tunables 0 0 0 : slabdata 1 1 0 kmalloc-131072 4 4 131072 4 8 : tunables 0 0 0 : slabdata 1 1 0 kmalloc-65536 376 376 65536 8 8 : tunables 0 0 0 : slabdata 47 47 0 kmalloc-32768 320 320 32768 16 8 : tunables 0 0 0 : slabdata 20 20 0 kmalloc-16384 5248 5248 16384 32 8 : tunables 0 0 0 : slabdata 164 164 0 kmalloc-8192 2176 2176 8192 32 4 : tunables 0 0 0 : slabdata 68 68 0 kmalloc-4096 4452 4576 4096 32 2 : tunables 0 0 0 : slabdata 143 143 0 kmalloc-2048 4416 4416 2048 32 1 : tunables 0 0 0 : slabdata 138 138 0 kmalloc-1024 10048 10176 1024 64 1 : tunables 0 0 0 : slabdata 159 159 0 kmalloc-512 19071 19584 512 128 1 : tunables 0 0 0 : slabdata 153 153 0 kmalloc-256 75873 77312 256 256 1 : tunables 0 0 0 : slabdata 302 302 0 kmalloc-128 82078 85504 128 512 1 : tunables 0 0 0 : slabdata 167 167 0 > I would expect kmalloc to give you something that is cache-line aligned, > but probably nothing more than that. Now, I'd happily be proven wrong, > but so far, all I can see is that: > > - ARCH_KMALLOC_MINALIGN is defined as ARCH_DMA_MINALIGN > - ARCH_DMA_MINALIGN is defined as L1_CACHE_BYTES > - L1_CACHE_BYTES is 128 on arm64, and either 32, 64, or 128 on arm. > Kmalloc always allocates memory with size=roundup_pow_of_two(size) and address alignment roundup_pow_of_two(size). > What am I missing? > > Thanks, > > M. > -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs 2017-06-21 1:22 ` Shanker Donthineni @ 2017-06-21 7:30 ` Marc Zyngier 0 siblings, 0 replies; 6+ messages in thread From: Marc Zyngier @ 2017-06-21 7:30 UTC (permalink / raw) To: linux-arm-kernel On 21/06/17 02:22, Shanker Donthineni wrote: > Hi Marc, > > On 05/06/2017 06:25 AM, Marc Zyngier wrote: >> On Fri, May 05 2017 at 11:04:22 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: >>> Hi Marc, >>> >>> >>> On 05/02/2017 11:16 AM, Marc Zyngier wrote: >>>> On Sun, Apr 30 2017 at 3:36:15 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote: >>>>> We are always allocating extra 255Bytes of memory to handle ITE >>>>> physical address alignment requirement. The kmalloc() satisfies >>>>> the ITE alignment since the ITS driver is requesting a minimum >>>>> size of ITS_ITT_ALIGN bytes. >>>>> >>>>> Let's try to allocate the exact amount of memory that is required >>>>> for ITEs to avoid wastage. >>>>> >>>>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> >>>>> --- >>>>> Changes: >>>>> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit. >>>>> v3: changed from IITE to ITE. >>>>> v3: removed fallback since kmalloc() guarantees the right alignment. >>>>> >>>>> drivers/irqchip/irq-gic-v3-its.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >>>>> index 45ea1933..72e56f03 100644 >>>>> --- a/drivers/irqchip/irq-gic-v3-its.c >>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>>>> @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd, >>>>> u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); >>>>> >>>>> itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); >>>>> - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN); >>>>> >>>>> its_encode_cmd(cmd, GITS_CMD_MAPD); >>>>> its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id); >>>>> @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, >>>>> */ >>>>> nr_ites = max(2UL, roundup_pow_of_two(nvecs)); >>>>> sz = nr_ites * its->ite_size; >>>>> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; >>>>> + sz = max(sz, ITS_ITT_ALIGN); >>>>> itt = kzalloc(sz, GFP_KERNEL); >>>>> lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis); >>>>> if (lpi_map) >>>>> col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL); >>>>> >>>>> - if (!dev || !itt || !lpi_map || !col_map) { >>>>> + if (!dev || !itt || !lpi_map || !col_map || >>>>> + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) { >>>>> kfree(dev); >>>>> kfree(itt); >>>>> kfree(lpi_map); >>>> I'm confused. Either the alignment is guaranteed (and you should >>>> document why it is so), or it is not, and we need to handle the >>>> non-alignment (instead of failing). >>> >>> Sorry for confusion, alignment is guaranteed by kmalloc(), added a >>> check for readability purpose only can be removed. >> >> My question still remains. Where exactly is that alignment guarantee >> documented and enforced? I can't see anything giving that certainty. >> > > The internal implementation of kmalloc() uses the slab/slub feature > to allocate memory from 2^N size pool. Linux kernel maintains the > fixed size of kmem_cache pools to serve the kmalloc(), It allocates > minimum size of 128Bytes and maximum size depends on the system > configuration and memory availability. In fact SMMUv3 driver has a > similar requirement and absolutely there no problem using kmalloc() > to meet the address alignment requirement. > > Call trace: > kmalloc() > kmalloc_slab() --> convert size to kmem_cache > slab_alloc() ---> allocate 2^N size kmem_cache object > > root at null-8cfdf006971f:~# cat /proc/slabinfo | grep kmall > dma-kmalloc-131072 0 0 131072 4 8 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-65536 0 0 65536 8 8 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-32768 0 0 32768 16 8 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-16384 0 0 16384 32 8 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-8192 0 0 8192 32 4 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-4096 0 0 4096 32 2 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-2048 0 0 2048 32 1 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-1024 0 0 1024 64 1 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-512 128 128 512 128 1 : tunables 0 0 0 : slabdata 1 1 0 > dma-kmalloc-256 0 0 256 256 1 : tunables 0 0 0 : slabdata 0 0 0 > dma-kmalloc-128 512 512 128 512 1 : tunables 0 0 0 : slabdata 1 1 0 > kmalloc-131072 4 4 131072 4 8 : tunables 0 0 0 : slabdata 1 1 0 > kmalloc-65536 376 376 65536 8 8 : tunables 0 0 0 : slabdata 47 47 0 > kmalloc-32768 320 320 32768 16 8 : tunables 0 0 0 : slabdata 20 20 0 > kmalloc-16384 5248 5248 16384 32 8 : tunables 0 0 0 : slabdata 164 164 0 > kmalloc-8192 2176 2176 8192 32 4 : tunables 0 0 0 : slabdata 68 68 0 > kmalloc-4096 4452 4576 4096 32 2 : tunables 0 0 0 : slabdata 143 143 0 > kmalloc-2048 4416 4416 2048 32 1 : tunables 0 0 0 : slabdata 138 138 0 > kmalloc-1024 10048 10176 1024 64 1 : tunables 0 0 0 : slabdata 159 159 0 > kmalloc-512 19071 19584 512 128 1 : tunables 0 0 0 : slabdata 153 153 0 > kmalloc-256 75873 77312 256 256 1 : tunables 0 0 0 : slabdata 302 302 0 > kmalloc-128 82078 85504 128 512 1 : tunables 0 0 0 : slabdata 167 167 0 > > >> I would expect kmalloc to give you something that is cache-line aligned, >> but probably nothing more than that. Now, I'd happily be proven wrong, >> but so far, all I can see is that: >> >> - ARCH_KMALLOC_MINALIGN is defined as ARCH_DMA_MINALIGN >> - ARCH_DMA_MINALIGN is defined as L1_CACHE_BYTES >> - L1_CACHE_BYTES is 128 on arm64, and either 32, 64, or 128 on arm. >> > > Kmalloc always allocates memory with size=roundup_pow_of_two(size) > and address alignment roundup_pow_of_two(size). Again, where is that enforced? The slob allocator explicitly uses ARCH_KMALLOC_MINALIGN to compute its alignment. How does that match your description above? Where is this roundup_pow_of_two(size) you're quoting? Does it actually apply to all 3 allocators we have in the kernel? Please don't give me any of this "it works for me". Show me the code ;-) Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-21 7:30 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-30 14:36 [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs Shanker Donthineni 2017-05-02 16:16 ` Marc Zyngier 2017-05-05 22:04 ` Shanker Donthineni 2017-05-06 11:25 ` Marc Zyngier 2017-06-21 1:22 ` Shanker Donthineni 2017-06-21 7:30 ` Marc Zyngier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).