-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inet/(TCP/UDP)Endpoints: Migrate from SystemPool to BitMapObjectPool #11428
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the consensus is to migrate all pool management to dynamic based pool, not the other way around.
We have spent huge effort to convert system pool to support dynamic allocation which can save significant memory usage on enabled platforms, we should not simply dump all of our those works without clear justification.
PR #11428: Size comparison from 1538bbb to 01f4929 Increases above 0.2%:
Increases (18 builds for linux, nrfconnect, telink)
Decreases (18 builds for linux, nrfconnect, telink)
Full report (19 builds for linux, nrfconnect, telink)
|
After sync-up, this PR is the transitional change. #11428 is the transitional plan and Inet will temporarily use BitMapObjectPool and soon use the unified implementation with the same dynamic implementation option as now. |
PR #11428: Size comparison from abcae0d to a6ec444 Increases above 0.2%:
Increases (13 builds for efr32, k32w, p6, qpg, telink)
Decreases (12 builds for efr32, k32w, p6, qpg, telink)
Full report (13 builds for efr32, k32w, p6, qpg, telink)
|
It looks like the +328 or +632 byes memory usage on variety platforms are due to
The TCP endpoint pool is not linked previously because there is no TCP usage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments noted inline.
In general, this seems like it makes sense. The retain/release calls on the two sides of the queue make sense and simplifies things.
I think LwIPHandleIncomingConnection could use rework though. There's way to much reference count manipulation happening there. I honestly can't tell whether the code is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice simplification of LayerLwIP!
#### Problem `Inet::TCPEndPoint` and `Inet::UDPEndPoint` historically could not use constructors because of `System::ObjectPool` limitations. Incidentally renamed `mAppState` for consistency (it had been in `System::Object` prior to project-chip#11428). This is a step toward project-chip#7715 _Virtualize System and Inet interfaces_, split off to reduce the complexity of an upcoming PR. #### Change overview Convert from `Init()` to constructors. Transitionally, the constructors still call a per-implementation function `InitImpl()`. #### Testing CI; no changes to functionality.
#### Problem `Inet::TCPEndPoint` and `Inet::UDPEndPoint` historically could not use constructors because of `System::ObjectPool` limitations. Incidentally renamed `mAppState` for consistency (it had been in `System::Object` prior to project-chip#11428). This is a step toward project-chip#7715 _Virtualize System and Inet interfaces_, split off to reduce the complexity of an upcoming PR. #### Change overview Convert from `Init()` to constructors. Transitionally, the constructors still call a per-implementation function `InitImpl()`. #### Testing CI; no changes to functionality.
#### Problem `Inet::TCPEndPoint` and `Inet::UDPEndPoint` historically could not use constructors because of `System::ObjectPool` limitations. Incidentally renamed `mAppState` for consistency (it had been in `System::Object` prior to project-chip#11428). This is a step toward project-chip#7715 _Virtualize System and Inet interfaces_, split off to reduce the complexity of an upcoming PR. #### Change overview Convert from `Init()` to constructors. Transitionally, the constructors still call a per-implementation function `InitImpl()`. #### Testing CI; no changes to functionality.
#### Problem `Inet::TCPEndPoint` and `Inet::UDPEndPoint` historically could not use constructors because of `System::ObjectPool` limitations. Incidentally renamed `mAppState` for consistency (it had been in `System::Object` prior to project-chip#11428). This is a step toward project-chip#7715 _Virtualize System and Inet interfaces_, split off to reduce the complexity of an upcoming PR. #### Change overview Convert from `Init()` to constructors. Transitionally, the constructors still call a per-implementation function `InitImpl()`. #### Testing CI; no changes to functionality.
* Inet: Use constructors for Inet EndPoints #### Problem `Inet::TCPEndPoint` and `Inet::UDPEndPoint` historically could not use constructors because of `System::ObjectPool` limitations. Incidentally renamed `mAppState` for consistency (it had been in `System::Object` prior to #11428). This is a step toward #7715 _Virtualize System and Inet interfaces_, split off to reduce the complexity of an upcoming PR. #### Change overview Convert from `Init()` to constructors. Transitionally, the constructors still call a per-implementation function `InitImpl()`. #### Testing CI; no changes to functionality. * explicitly initialize all members
#### Problem We have too many pool allocators. Previous PRs (project-chip#11428, project-chip#11487) transitionally use `BitMapObjectPool` where previously `System::ObjectPool` had been used, but this lost the ability to configure heap allocation. #### Change overview - Add a heap allocator (from project-chip#9590) - Add allocation selection (from project-chip#11371) - Use this for `System::Timer` (complementing project-chip#11487) Co-authored-by: Zang MingJie <zealot0630@gmail.com> Co-authored-by: C Freeman <cecille@google.com> A future PR will use this for Inet pools (complementing project-chip#11428); that is not done here because it would conflict with other Inet changes under way. #### Testing CI; no changes to functionality. CI should show `.bss` decreases corresponding to increases in project-chip#11487.
#### Problem We have too many pool allocators. Previous PRs (project-chip#11428, project-chip#11487) transitionally use `BitMapObjectPool` where previously `System::ObjectPool` had been used, but this lost the ability to configure heap allocation. #### Change overview - Add a heap allocator (from project-chip#9590) - Add allocation selection (from project-chip#11371) - Use this for `System::Timer` (complementing project-chip#11487) Co-authored-by: Zang MingJie <zealot0630@gmail.com> Co-authored-by: C Freeman <cecille@google.com> A future PR will use this for Inet pools (complementing project-chip#11428); that is not done here because it would conflict with other Inet changes under way. #### Testing Added heap versions of unit tests in TestPool. (A future PR will add `System::Object`-style statistics and re-unify most of these tests.) CI should show `.bss` decreases corresponding to increases in project-chip#11487.
#### Problem We have too many pool allocators. Previous PRs (project-chip#11428, project-chip#11487) transitionally use `BitMapObjectPool` where previously `System::ObjectPool` had been used, but this lost the ability to configure heap allocation. #### Change overview - Add a heap allocator (from project-chip#9590) - Add allocation selection (from project-chip#11371) - Use this for `System::Timer` (complementing project-chip#11487) Co-authored-by: Zang MingJie <zealot0630@gmail.com> Co-authored-by: C Freeman <cecille@google.com> A future PR will use this for Inet pools (complementing project-chip#11428); that is not done here because it would conflict with other Inet changes under way. #### Testing Added heap versions of unit tests in TestPool. (A future PR will add `System::Object`-style statistics and re-unify most of these tests.) CI should show `.bss` decreases corresponding to increases in project-chip#11487.
#### Problem We have too many pool allocators. Previous PRs (project-chip#11428, project-chip#11487) transitionally use `BitMapObjectPool` where previously `System::ObjectPool` had been used, but this lost the ability to configure heap allocation. #### Change overview - Add a heap allocator (from project-chip#9590) - Add allocation selection (from project-chip#11371) - Use this for `System::Timer` (complementing project-chip#11487) Co-authored-by: Zang MingJie <zealot0630@gmail.com> Co-authored-by: C Freeman <cecille@google.com> A future PR will use this for Inet pools (complementing project-chip#11428); that is not done here because it would conflict with other Inet changes under way. #### Testing Added heap versions of unit tests in TestPool. (A future PR will add `System::Object`-style statistics and re-unify most of these tests.) CI should show `.bss` decreases corresponding to increases in project-chip#11487.
#### Problem We have too many pool allocators. Previous PRs (project-chip#11428, project-chip#11487) transitionally use `BitMapObjectPool` where previously `System::ObjectPool` had been used, but this lost the ability to configure heap allocation. #### Change overview - Add a heap allocator (from project-chip#9590) - Add allocation selection (from project-chip#11371) - Use this for `System::Timer` (complementing project-chip#11487) Co-authored-by: Zang MingJie <zealot0630@gmail.com> Co-authored-by: C Freeman <cecille@google.com> A future PR will use this for Inet pools (complementing project-chip#11428); that is not done here because it would conflict with other Inet changes under way. #### Testing Added heap versions of unit tests in TestPool. (A future PR will add `System::Object`-style statistics and re-unify most of these tests.) CI should show `.bss` decreases corresponding to increases in project-chip#11487.
#### Problem We have too many pool allocators. Previous PRs (#11428, #11487) transitionally use `BitMapObjectPool` where previously `System::ObjectPool` had been used, but this lost the ability to configure heap allocation. #### Change overview - Add a heap allocator (from #9590) - Add allocation selection (from #11371) - Use this for `System::Timer` (complementing #11487) - Factor out common code. - Use a heap-allocated list to track heap-allocated objects. - More unit tests. Co-authored-by: Zang MingJie <zealot0630@gmail.com> Co-authored-by: C Freeman <cecille@google.com> A future PR will use this for Inet pools (complementing #11428); that is not done here because it would conflict with other Inet changes under way. #### Testing Added heap versions of unit tests in TestPool. (A future PR will add `System::Object`-style statistics and re-unify most of these tests.) CI should show `.bss` decreases corresponding to increases in #11487.
…roject-chip#11428) * Migrate inet/endpoints to BitMapPool * Remove atomic
* Inet: Use constructors for Inet EndPoints #### Problem `Inet::TCPEndPoint` and `Inet::UDPEndPoint` historically could not use constructors because of `System::ObjectPool` limitations. Incidentally renamed `mAppState` for consistency (it had been in `System::Object` prior to project-chip#11428). This is a step toward project-chip#7715 _Virtualize System and Inet interfaces_, split off to reduce the complexity of an upcoming PR. #### Change overview Convert from `Init()` to constructors. Transitionally, the constructors still call a per-implementation function `InitImpl()`. #### Testing CI; no changes to functionality. * explicitly initialize all members
Problem
Use BitMapObjectPool as basic pool implementation, deprecate
SystemPool
, will introduce a dynamic pool later, sharing same interface asBitMapObjectPool
for Linux and Darwin platformChange overview
SystemPool
toBitMapObjectPool
ScheduleLambda
instead ofPostEvent
, remove inet event dispatcherRetain
before queuing the endpoint into the event queue, callRelease
after the event is processed, removeDeferralFree
Testing
Verified using unit-tests