* [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).