From: Zhu Lingshan <lingshan.zhu@amd.com>
To: "Chen, Xiaogang" <xiaogang.chen@amd.com>, amd-gfx@lists.freedesktop.org
Cc: felix.kuehling@amd.com, philip.yang@amd.com
Subject: Re: [PATCH v2] drm/amdkfd: change kfd process kref count at creation
Date: Mon, 14 Oct 2024 09:55:29 +0800 [thread overview]
Message-ID: <2da699ed-634d-4710-9539-a28ede17c41b@amd.com> (raw)
In-Reply-To: <15671ab9-264c-4a4e-bb28-8c4da30271b9@amd.com>
On 10/13/2024 1:30 AM, Chen, Xiaogang wrote:
>
> On 10/11/2024 9:56 PM, Zhu Lingshan wrote:
>> On 10/11/2024 10:41 PM, Xiaogang.Chen wrote:
>>> From: Xiaogang Chen <xiaogang.chen@amd.com>
>>>
>>> kfd process kref count(process->ref) is initialized to 1 by kref_init. After
>>> it is created not need to increaes its kref. Instad add kfd process kref at kfd
>>> process mmu notifier allocation since we decrease the ref at free_notifier of
>>> mmu_notifier_ops, so pair them.
>>>
>>> When user process opens kfd node multiple times the kfd process kref is
>>> increased each time to balance kfd node close operation.
>>>
>>> Signed-off-by: Xiaogang Chen <Xiaogang.Chen@amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> index d07acf1b2f93..78bf918abf92 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> @@ -850,8 +850,10 @@ struct kfd_process *kfd_create_process(struct task_struct *thread)
>>> goto out;
>>> }
>>> - /* A prior open of /dev/kfd could have already created the process. */
>>> - process = find_process(thread, false);
>>> + /* A prior open of /dev/kfd could have already created the process.
>>> + * find_process will increase process kref in this case
>>> + */
>>> + process = find_process(thread, true);
>>> if (process) {
>>> pr_debug("Process already found\n");
>>> } else {
>>> @@ -899,8 +901,6 @@ struct kfd_process *kfd_create_process(struct task_struct *thread)
>>> init_waitqueue_head(&process->wait_irq_drain);
>>> }
>>> out:
>>> - if (!IS_ERR(process))
>>> - kref_get(&process->ref);
>>> mutex_unlock(&kfd_processes_mutex);
>>> mmput(thread->mm);
>>> @@ -1191,7 +1191,12 @@ static struct mmu_notifier *kfd_process_alloc_notifier(struct mm_struct *mm)
>>> srcu_read_unlock(&kfd_processes_srcu, idx);
>>> - return p ? &p->mmu_notifier : ERR_PTR(-ESRCH);
>>> + if (p) {
>>> + kref_get(&p->ref);
>>> + return &p->mmu_notifier;
>>> + }
>>> +
>>> + return ERR_PTR(-ESRCH);
>> this cb should only allocate the notifier (here it returns an existing notifier ),
>> so I am not sure this is a better place to increase the kref, it seems coupling
>> two low correlated routines.
>>
>> kref is decreased in the free notifier, but not mean it has to be increased in alloc notifier.
>
> Who referring kfd process should also un-referrer it after finish. Any client should not do un-refer if it did not refer. That keeps balance in clean way.
I think we already do so, see any functions call kfd_lookup_process_by_xxx would unref the kref of the kfd_process.
>
> The current way is using mmu's free notifier to unref kfref that was added by kfd process creation. Ex: if not use mmu notifier there would be extra kref that prevent release kfd process.
I am not sure this is about paring, current design is to free the last kref when the whole program exits by the mmu free notifier, so it would destroy the kfd_process.
MMU free notifier would be certainly invoked since it has been registered.
Thanks
Lingshan
>
> The final kref is same. The patch just makes the balance in a logical way.
>
> Regards
>
> Xiaogang
>
>>
>> Thanks
>> Lingshan
>>
>>> static void kfd_process_free_notifier(struct mmu_notifier *mn)
next prev parent reply other threads:[~2024-10-14 1:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 14:41 [PATCH v2] drm/amdkfd: change kfd process kref count at creation Xiaogang.Chen
2024-10-12 2:56 ` Zhu Lingshan
2024-10-12 17:30 ` Chen, Xiaogang
2024-10-14 1:55 ` Zhu Lingshan [this message]
2024-10-14 15:07 ` Chen, Xiaogang
2024-10-15 2:51 ` Zhu Lingshan
2024-10-15 4:49 ` Chen, Xiaogang
2024-10-18 19:14 ` Felix Kuehling
2024-10-18 22:02 ` Chen, Xiaogang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2da699ed-634d-4710-9539-a28ede17c41b@amd.com \
--to=lingshan.zhu@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=philip.yang@amd.com \
--cc=xiaogang.chen@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox