>> @@ -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.
Thanks,
Wendy
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
------------------------------------------------------------------------------
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
