On 04/11/2016 02:07 PM, Wen Xiong wrote:
>>> @@ -9587,11 +9673,25 @@ static int ipr_alloc_mem(struct ipr_ioa_cfg
>>> *ioa_cfg)
>>> if (!ioa_cfg->trace)
>>> goto out_free_hostrcb_dma;
>>>
>>> + if (ioa_cfg->cpu_map) {
>>> + ioa_cfg->cpu_map_tbl =
>>> + kzalloc(sizeof(struct ipr_vector_map_info) *
>>> + ioa_cfg->possible_cpu_cnt, GFP_KERNEL);
>>> +
>>> + if (!ioa_cfg->cpu_map_tbl)
>>> + goto out_free_trace;
>>> + }
>>> +
>>> + for (i = 0; i < ipr_possible_cpu_cnt; i++)
>>> + ipr_used_cpu[i] = IPR_VECTOR_MAP_EMPTY;
>
>>It seems like this shouldn't be a global. You seem to only use it at probe
>>time, so I
>>can see why you made it a global, but it just seems wrong. Seems like we
>>should either
>>allocate this temp buffer dynamically at probe time, then free it, since it
>>seems to be
>>needed only during probe, or we do something different. Perhaps another
>>approach
>>would be to just define a bitmap in ioa_cfg like:
>
>>unsigned long used_cpu[(NR_CPUS / BITS_PER_LONG) + 1] and then use bitops to
>>access and set the bits.
>>Then we'd likely just leave the memory around, since it wouldn't be very
>>large.
>
> Hi Brian,
>
> ipr_used_cpu is a global according to the cpu affinity mapping which we want
> to implement. For example:
>
> ipr driver cpu map: IRQ vector to CPU mapping (1): 32 online CPUs
> CPU 00 io_hrrq 00 IRQ=224 ----> (cpu 00 to cpu 16) are binding to (irq 224
> to 239).
> CPU 01 io_hrrq 01 IRQ=225
> CPU 02 io_hrrq 02 IRQ=226
> CPU 03 io_hrrq 03 IRQ=227
> CPU 04 io_hrrq 04 IRQ=228
> CPU 05 io_hrrq 05 IRQ=229
> CPU 06 io_hrrq 06 IRQ=230
> CPU 07 io_hrrq 07 IRQ=231
> CPU 08 io_hrrq 08 IRQ=232
> CPU 09 io_hrrq 09 IRQ=233
> CPU 10 io_hrrq 10 IRQ=234
> CPU 11 io_hrrq 11 IRQ=235
> CPU 12 io_hrrq 12 IRQ=236
> CPU 13 io_hrrq 13 IRQ=237
> CPU 14 io_hrrq 14 IRQ=238
> CPU 15 io_hrrq 15 IRQ=239
> CPU 16 io_hrrq 00 IRQ=480 -----> (cpu 16 to cpu 31) are binding to (irq 480
> to irq 495)
> CPU 17 io_hrrq 01 IRQ=481
> CPU 18 io_hrrq 02
> CPU 19 io_hrrq 03
> CPU 20 io_hrrq 04
> CPU 21 io_hrrq 05
> CPU 22 io_hrrq 06
> CPU 23 io_hrrq 07
> CPU 24 io_hrrq 08
> CPU 25 io_hrrq 09
> CPU 26 io_hrrq 10
> CPU 27 io_hrrq 11
> CPU 28 io_hrrq 12
> CPU 29 io_hrrq 13
> CPU 30 io_hrrq 14
> CPU 31 io_hrrq 15 IRQ=495
>
>
> I can change it to use bits op but probably have to keep it as a global.
Ok. Thanks for the picture here. That helps. In that case, do we really want to
be
re-initializing ipr_used_cpu in ipr_alloc_mem, which gets called at probe
time for each adapter? Changing to atomic bit ops would be good to ensure we
don't have issues with multiple adapters getting probed at the same time.
Thanks,
Brian
>
> Thanks,
> Wendy
> Inactive hide details for Brian King ---03/13/2016 05:06:15 PM---On
> 03/09/2016 03:45 PM, wenxi...@linux.vnet.ibm.com wrote: > FBrian King
> ---03/13/2016 05:06:15 PM---On 03/09/2016 03:45 PM,
> wenxi...@linux.vnet.ibm.com wrote: > From: Wen Xiong <wenxi...@linux.vnet.ib
>
> From: Brian King <brk...@linux.vnet.ibm.com>
> To: wenxi...@linux.vnet.ibm.com, iprdd-devel@lists.sourceforge.net
> Date: 03/13/2016 05:06 PM
> Subject: Re: [Iprdd-devel] [V3 PATCH 2/4] Enable vectors to cpu affinity
> mapping
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
---
>
>
>
>
>> @@ -9587,11 +9673,25 @@ static int ipr_alloc_mem(struct ipr_ioa_cfg *ioa_cfg)
>> if (!ioa_cfg->trace)
>> goto out_free_hostrcb_dma;
>>
>> + if (ioa_cfg->cpu_map) {
>> + ioa_cfg->cpu_map_tbl =
>> + kzalloc(sizeof(struct ipr_vector_map_info) *
>> + ioa_cfg->possible_cpu_cnt, GFP_KERNEL);
>> +
>> + if (!ioa_cfg->cpu_map_tbl)
>> + goto out_free_trace;
>> + }
>> +
>> + for (i = 0; i < ipr_possible_cpu_cnt; i++)
>> + ipr_used_cpu[i] = IPR_VECTOR_MAP_EMPTY;
>
> It seems like this shouldn't be a global. You seem to only use it at probe
> time, so I
> can see why you made it a global, but it just seems wrong. Seems like we
> should either
> allocate this temp buffer dynamically at probe time, then free it, since it
> seems to be
> needed only during probe, or we do something different. Perhaps another
> approach
> would be to just define a bitmap in ioa_cfg like:
>
> unsigned long used_cpu[(NR_CPUS / BITS_PER_LONG) + 1] and then use bitops to
> access and set the bits.
> Then we'd likely just leave the memory around, since it wouldn't be very
> large.
>
> And if we change cpu_id above, then this should become an unsigned int as
> well.
>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Iprdd-devel mailing list
> Iprdd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iprdd-devel
>
>
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Iprdd-devel mailing list
Iprdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iprdd-devel
