From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de
Cc: fenghua.yu@intel.com, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, paulmck@kernel.org,
akpm@linux-foundation.org, quic_neeraju@quicinc.com,
rdunlap@infradead.org, damien.lemoal@opensource.wdc.com,
songmuchun@bytedance.com, peterz@infradead.org,
jpoimboe@kernel.org, pbonzini@redhat.com,
chang.seok.bae@intel.com, pawan.kumar.gupta@linux.intel.com,
jmattson@google.com, daniel.sneddon@linux.intel.com,
sandipan.das@amd.com, tony.luck@intel.com, james.morse@arm.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
bagasdotme@gmail.com, eranian@google.com,
christophe.leroy@csgroup.eu, jarkko@kernel.org,
adrian.hunter@intel.com, quic_jiles@quicinc.com,
peternewman@google.com
Subject: Re: [PATCH v5 7/8] x86/resctrl: Move default control group creation during mount
Date: Fri, 14 Jul 2023 17:42:26 -0500 [thread overview]
Message-ID: <1fcf1463-7d4c-ae6a-0c05-2e1bbf081846@amd.com> (raw)
In-Reply-To: <8f68ace7-e05b-ad6d-fa74-5ff8e179aec9@intel.com>
Hi Reinette,
On 7/14/23 16:54, Reinette Chatre wrote:
> Hi Babu,
>
> On 7/14/2023 9:26 AM, Moger, Babu wrote:
>> Hi Reinette,
>> Sorry.. Took a while to respond. I had to recreate the issue to refresh my
>> memory.
>
> No problem!
>
>> On 7/7/23 16:46, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> On 6/1/2023 12:02 PM, Babu Moger wrote:
>
>
>>>> ctx = kzalloc(sizeof(struct rdt_fs_context), GFP_KERNEL);
>>>> - if (!ctx)
>>>> + if (!ctx) {
>>>> + kernfs_destroy_root(rdt_root);
>>>> return -ENOMEM;
>>>> + }
>>>>
>>>> ctx->kfc.root = rdt_root;
>>>> ctx->kfc.magic = RDTGROUP_SUPER_MAGIC;
>>>> @@ -2845,6 +2860,9 @@ static void rdt_kill_sb(struct super_block *sb)
>>>> static_branch_disable_cpuslocked(&rdt_alloc_enable_key);
>>>> static_branch_disable_cpuslocked(&rdt_mon_enable_key);
>>>> static_branch_disable_cpuslocked(&rdt_enable_key);
>>>> + /* Remove the default group and cleanup the root */
>>>> + list_del(&rdtgroup_default.rdtgroup_list);
>>>> + kernfs_destroy_root(rdt_root);
>>>
>>> Why not just add kernfs_remove(rdtgroup_default.kn) to rmdir_all_sub()?
>>
>> List rdtgroup_default.rdtgroup_list is added during the mount and had to
>> be removed during umount and rdt_root is destroyed here.
>
> I do not think it is required for default resource group management to
> be tied with the resctrl files associated with default resource group.
>
> I think rdtgroup_setup_root can be split in two, one for all the
> resctrl files that should be done at mount/unmount and one for the
> default group init done at __init.
Ok.
>
>>>> kernfs_kill_sb(sb);
>>>> mutex_unlock(&rdtgroup_mutex);
>>>> cpus_read_unlock();
>>>> @@ -3598,10 +3616,8 @@ static struct kernfs_syscall_ops rdtgroup_kf_syscall_ops = {
>>>> .show_options = rdtgroup_show_options,
>>>> };
>>>>
>>>> -static int __init rdtgroup_setup_root(void)
>>>> +static int rdtgroup_setup_root(void)
>>>> {
>>>> - int ret;
>>>> -
>>>> rdt_root = kernfs_create_root(&rdtgroup_kf_syscall_ops,
>>>> KERNFS_ROOT_CREATE_DEACTIVATED |
>>>> KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK,
>>>> @@ -3618,19 +3634,11 @@ static int __init rdtgroup_setup_root(void)
>>>>
>>>> list_add(&rdtgroup_default.rdtgroup_list, &rdt_all_groups);
>>>>
>>>> - ret = rdtgroup_add_files(kernfs_root_to_node(rdt_root), RFTYPE_CTRL_BASE);
>>>> - if (ret) {
>>>> - kernfs_destroy_root(rdt_root);
>>>> - goto out;
>>>> - }
>>>> -
>>>> rdtgroup_default.kn = kernfs_root_to_node(rdt_root);
>>>> - kernfs_activate(rdtgroup_default.kn);
>>>>
>>>> -out:
>>>> mutex_unlock(&rdtgroup_mutex);
>>>>
>>>> - return ret;
>>>> + return 0;
>>>> }
>>>>
>>>> static void domain_destroy_mon_state(struct rdt_domain *d)
>>>> @@ -3752,13 +3760,9 @@ int __init rdtgroup_init(void)
>>>> seq_buf_init(&last_cmd_status, last_cmd_status_buf,
>>>> sizeof(last_cmd_status_buf));
>>>>
>>>> - ret = rdtgroup_setup_root();
>>>> - if (ret)
>>>> - return ret;
>>>> -
>>>> ret = sysfs_create_mount_point(fs_kobj, "resctrl");
>>>> if (ret)
>>>> - goto cleanup_root;
>>>> + return ret;
>>>>
>>>
>>> It is not clear to me why this change is required, could you
>>> please elaborate? It seems that all that is needed is for
>>> rdtgroup_add_files() to move to rdt_get_tree() (which you have done)
>>> and then an additional call to kernfs_remove() in rmdir_all_sub().
>>> I must be missing something, could you please help me understand?
>>>
>>
>> Yes. I started with that approach. But there are issues with that approach.
>>
>> Currently, rdt_root(which is rdtgroup_default.kn) is created during
>> rdtgroup_init. At the same time the root files are created. Also, default
>> group is added to rdt_all_groups. Basically, the root files and
>> rdtgroup_default group is always there even though filesystem is never
>> mounted. Also mbm_over and cqm_limbo workqueues are always running even
>> though filesystem is not mounted.
>>
>> I changed rdtgroup_add_files() to move to rdt_get_tree() and added
>> kernfs_remove() in rmdir_all_sub(). This caused problems. The
>> kernfs_remove(rdtgroup_default.kn) removes all the reference counts and
>> releases the root. When we mount again, we hit this this problem below.
>>
>> [ 404.558461] ------------[ cut here ]------------
>> [ 404.563631] WARNING: CPU: 35 PID: 7728 at fs/kernfs/dir.c:522
>> kernfs_new_node+0x63/0x70
>>
>> 404.778793] ? __warn+0x81/0x140
>> [ 404.782535] ? kernfs_new_node+0x63/0x70
>> [ 404.787036] ? report_bug+0x102/0x200
>> [ 404.791247] ? handle_bug+0x3f/0x70
>> [ 404.795269] ? exc_invalid_op+0x13/0x60
>> [ 404.799671] ? asm_exc_invalid_op+0x16/0x20
>> [ 404.804461] ? kernfs_new_node+0x63/0x70
>> [ 404.808954] ? snprintf+0x49/0x70
>> [ 404.812762] __kernfs_create_file+0x30/0xc0
>> [ 404.817534] rdtgroup_add_files+0x6c/0x100
>>
>> Basically kernel says your rdt_root is not initialized. That is the reason
>> I had to move everything to mount time. The rdt_root is created and
>> initialized during the mount and also destroyed during the umount.
>> And I had to move rdt_enable_key check during rdt_root creation.
>>
>
> ok, thank you for the additional details. I see now how this patch evolved.
> I understand how rdt_root needs to be created/destroyed
> during mount/unmount. If I understand correctly the changes to
> rdt_init_fs_context() was motivated by this line:
>
> ctx->kfc.root = rdt_root;
>
> ... that prompted you to move rdt_root creation there in order to have
> it present for this assignment and that prompted the
> rdt_enable_key check to follow. Is this correct?
That is correct.
>
> I am concerned about the changes to rdt_init_fs_context() since it further
> separates the resctrl file management, it breaks the symmetry of the
> key checked and set, and finally these new actions seem unrelated to a function
> named "init_fs_context". I looked at other examples and from what I can tell
> it is not required that ctx->kfc.root be initialized within
> rdt_init_fs_context(). Looks like the value is required by kernfs_get_tree()
> that is called from rdt_get_tree(). For comparison I found cgroup_do_get_tree().
> Note how cgroup_do_get_tree(), within the .get_tree callback,
> initializes kernfs_fs_context.root and then call kernfs_get_tree()?
Yes. I see that. Thanks for pointing.
>
> It thus looks to me as though things can be simplified significantly
> if the kernfs_fs_context.root assignment is moved from rdt_init_fs_context()
> to rdt_get_tree(). rdt_get_tree() can then create rdt_root (and add all needed
> files), assign it to kernfs_fs_context.root and call kernfs_get_tree().
>
> What do you think?
Yes. I think we can do that. Let me try it. Will let you know how it goes.
Thanks for the suggestion.
--
Thanks
Babu Moger
next prev parent reply other threads:[~2023-07-14 22:42 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 19:00 [PATCH v5 0/8] x86/resctrl: Miscellaneous resctrl features Babu Moger
2023-06-01 19:00 ` [PATCH v5 1/8] x86/resctrl: Add multiple tasks to the resctrl group at once Babu Moger
2023-07-07 21:38 ` Reinette Chatre
2023-07-11 17:54 ` Moger, Babu
2023-06-01 19:01 ` [PATCH v5 2/8] x86/resctrl: Simplify rftype flag definitions Babu Moger
2023-07-07 21:38 ` Reinette Chatre
2023-06-01 19:01 ` [PATCH v5 3/8] x86/resctrl: Rename rftype flags for consistency Babu Moger
2023-07-07 21:38 ` Reinette Chatre
2023-06-01 19:01 ` [PATCH v5 4/8] x86/resctrl: Add comments on RFTYPE flags hierarchy Babu Moger
2023-07-07 21:39 ` Reinette Chatre
2023-07-11 23:19 ` Moger, Babu
2023-06-01 19:01 ` [PATCH v5 5/8] x86/resctrl: Introduce "-o debug" mount option Babu Moger
2023-07-07 21:42 ` Reinette Chatre
2023-07-12 16:40 ` Moger, Babu
2023-06-01 19:01 ` [PATCH v5 6/8] x86/resctrl: Display CLOSID and RMID for the resctrl groups Babu Moger
2023-07-07 21:45 ` Reinette Chatre
2023-07-12 19:36 ` Moger, Babu
2023-07-14 21:53 ` Reinette Chatre
2023-07-14 22:45 ` Moger, Babu
2023-06-01 19:02 ` [PATCH v5 7/8] x86/resctrl: Move default control group creation during mount Babu Moger
2023-07-07 21:46 ` Reinette Chatre
2023-07-14 16:26 ` Moger, Babu
2023-07-14 21:54 ` Reinette Chatre
2023-07-14 22:42 ` Moger, Babu [this message]
2023-06-01 19:02 ` [PATCH v5 8/8] x86/resctrl: Introduce RFTYPE_DEBUG flag Babu Moger
2023-07-07 21:47 ` Reinette Chatre
2023-07-14 16:44 ` Moger, Babu
2023-06-27 14:26 ` [PATCH v5 0/8] x86/resctrl: Miscellaneous resctrl features Moger, Babu
2023-06-28 2:13 ` Shaopeng Tan (Fujitsu)
2023-07-11 16:34 ` Moger, Babu
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=1fcf1463-7d4c-ae6a-0c05-2e1bbf081846@amd.com \
--to=babu.moger@amd.com \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bagasdotme@gmail.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=christophe.leroy@csgroup.eu \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=quic_jiles@quicinc.com \
--cc=quic_neeraju@quicinc.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=sandipan.das@amd.com \
--cc=songmuchun@bytedance.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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