dax: set instance lifespan from prepare to reset#10526
dax: set instance lifespan from prepare to reset#10526checkupup wants to merge 1 commit intothesofproject:mainfrom
Conversation
checkupup
requested review from
dbaluta,
kv2019i,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
|
PR that references #10503 |
|
Can one of the admins verify this patch?
|
At present, dax instance is initialized and allocated inner buffer on module_init(), and released on module_free(). The memory requirement for the inner buffer per instance is quite large. The existing implementation has 2 pipelines containing dax. Even though the host is restricted from processing stream on both pipelines simultaneously, they may coexist with each other under some circumstances e.g. the interim when switching PCM device from one to the other, which may drain out the memory. This commit changes the timing of instance allocation/deallocation to module_prepare()/reset() respectively. That is, dax instance only occupies the inner buffer memory when processing. Signed-off-by: Johny Lin <johnylin@google.com>
checkupup
force-pushed
the
main_dax_alloc
branch
from
a4b3874 to
9411997
Compare
johnylin76
left a comment
johnylin76
left a comment
There was a problem hiding this comment.
LGTM in overall. please help to test them.
| struct sof_dax *dax_ctx = module_get_private_data(mod); | ||
|
|
||
| /* dax instance will be established on prepare(), and destroyed on reset() */ | ||
| destroy_instance(mod); |
There was a problem hiding this comment.
maybe also add if (dax_ctx) check to protect these lines
although I'm not sure if it can be reached. We can always be safe.
| comp_err(dev, "dax instance initialization failed, ret %d", ret); | ||
| goto err; | ||
| } | ||
| dax_ctx->update_flags |= DAX_ENABLE_MASK; |
There was a problem hiding this comment.
recommend to add a comment here
/* set DAX_ENABLE_MASK bit to trigger the fully update of kcontrol values */
|
@checkupup @johnylin76 I think we need to consider that DSPs are quite memory constrained devices and the asynchronous nature of PCM/pipeline creation/destruction within ALSA can easily lead to us with some heap fragmentation, especially when we need to allocate very large continuous buffers (and we had this problem with the key phrase buffer). e.g. please consider
If we can allocate the DAX memory resources at init() (by the 1st DAX instance) and then pass/share the resources between DAX instances then we dont have to worry about the heap fragmentation and other audio events. |
4 participants
At present, dax instance is initialized and allocated inner buffer on module_init(), and released on module_free(). The memory requirement for the inner buffer per instance is quite large.
The existing implementation has 2 pipelines containing dax. Even though the host is restricted from processing stream on both pipelines simultaneously, they may coexist with each other under some circumstances e.g. the interim when switching PCM device from one to the other, which may drain out the memory.
This commit changes the timing of instance allocation/deallocation to module_prepare()/reset() respectively. That is, dax instance only occupies the inner buffer memory when processing.