> On Nov 18, 2018, at 1:21 PM, Thomas Gleixner <t...@linutronix.de> wrote:
>
> Qian,
>
> On Sun, 18 Nov 2018, Qian Cai wrote:
>
>> The current value of ODEBUG_POOL_SIZE is not big enough for large memory
>> systems with timer or/and workqueue objects because during the early
>> boot, timer objects needs at least the size equals to
>>
>> No. CPUs x 2 (worker pool)
>>
>> start_kernel
>> workqueue_init_early
>> init_worker_pool
>> init_timer_key
>> debug_object_init
>>
>> puls, No. CPUs
>>
>> start_kernel
>> sched_init
>> hrtimer_init
>> debug_object_init
>>
>> Then, workqueue objects requires even more,
>>
>> No. CPUs x 2 (worker pool) x 6 (workqueue)
>>
>> start_kernel
>> workqueue_init_early
>> __alloc_workqueue_key
>> alloc_workqueue
>> init_pwq
>> debug_object_init
>>
>> plus, No, CPUs x 2 (worker pool)
>>
>> start_kernel
>> perf_event_init
>> __init_srcu_struct
>> init_srcu_struct_fields
>> __init_work
>> debug_object_init
>>
>> As the results, systems have 60+ CPUs with both timer and workqueue
>> objects enabled could trigger "ODEBUG: Out of memory. ODEBUG disabled".
>>
>> Hence, add a new Kconfig option so users could adjust ODEBUG_POOL_SIZE
>> accordingly if either timer or workqueue objects are selected.
>
> why do we need a config option, when the required number can be deduced
> already from the active CONFIG_DEBUG_OBJECTS_* and NR_CPUS?
>
It because I am worry about the coupling between the implementation details of
timers and workqueue objects, and the computation in the code you mentioned
here. For example, people could change workqueue.c to have different number
of worekqueues initialized during the early boot in the future which is going to
affect the required pool size, and I am not sure if people are going to adjust
the
code in debugobjects.c here as well when they made changes like that.
Also, the computation could become so complex depends on lots of config
options like perf, hrtimer, and combinations that I have not tested so far
which is
difficult to exhausted all the possibilities.
Hence, I feel like the Kconfig option is more flexible and less error-prone.
