From: Richard Palethorpe <rpalethorpe@suse.de>
To: Joerg Vehlow <lkml@jv-coder.de>
Cc: Joerg Vehlow <joerg.vehlow@aox-tech.de>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] cpuset_regression_test: Fix test, if cpuset groups exist already
Date: Tue, 23 Nov 2021 09:46:21 +0000 [thread overview]
Message-ID: <8735nnm9au.fsf@suse.de> (raw)
In-Reply-To: <e4927b0b-6b26-af58-0f7a-3f490c5fbff8@jv-coder.de>
Hello Joerg,
Joerg Vehlow <lkml@jv-coder.de> writes:
>>> +cpuset_find_breadth_first()
>>> +{
>>> + local what=$1
>>> +
>>> + # Breath first find implementation:
>>> + # Use awk to prepend the length of the path, sort it
>>> + # and remove the length again.
>>> + # Since all commands work line-based,
>>> + # this works with meta characters and spaces.
>>> + find . -mindepth 2 -name ${what} |
>>> + awk '{print length($0) " " $0}' |
>> This is the length of the path in characters. I think you want to count
>> the path components instead. The below is from my system
>>
>> find /sys/fs/cgroup -type d | awk '{print length($0) " " $0}' | sort -n
>> ...
>> 43 /sys/fs/cgroup/system.slice/wickedd.service
>> 44 /sys/fs/cgroup/sys-fs-fuse-connections.mount
>> ...
>>
>> sys-fs-fuse-connections.mount should come first in a breadth first
>> search.
> Actually it doesn't matter. The only thing, that matters here is that
> parent groups
> are handled before child groups. That is ensured, because the prefix
> of a child group is
> always the parent group and so the child is longer.
> At first I had it named "somewhat breadth-first" ;)
> Counting path components is not a trivial task, because there may be
> escaped slashes.
> Maybe not calling it breadth first, but parent-first would be a
> solution?
Sounds good, +1
>>
>>
>>> + sort -n | cut -d " " -f 2-
>>> +}
>>> +
>>> +# cpuset_backup_and_update <backup_dir> <what>
>>> # Create backup of the values of a specific file (<what>)
>>> -# in all cpuset groups and set the value to <value>
>>> +# in all cpuset groups and set the value to 1
>>> # The backup is written to <backup_dir> in the same structure
>>> # as in the cpuset filesystem
>>> cpuset_backup_and_update()
>>> {
>>> local backup_dir=$1
>>> local what=$2
>>> - local value=$3
>>> local old_dir=$PWD
>>> + local cpu_max=$((cpu_num - 1))
>>> + local res
>>> cd ${root_cpuset_dir}
>>> - find . -mindepth 2 -name ${what} -print0 |
>>> - while IFS= read -r -d '' file; do
>>> +
>>> + # First do breath-first search and set all groups to use all cpus.
>>> + # Breath-first is important, because the parent groups
>>> + # must have all cpus assigned to a child group first
>> This is confusing. Inline comments are not encouraged either. IMO the
>> commit message is enough or else you can add a brief explanation of the
>> saving and restore procedure at the top.
> Ok, I thought a bit of documentation why this is done would be a good
> idea, because it is not very obvious.
The main thing is that the comment doesn't make sense to me. In
particular the last sentence. Inline comments are also discouraged in
the style guide.
Also you can handle this depth-first, you just need to lift restrictions
before descending into the tree. So breadth-first is not really
important.
I think it's enough to explain at the top that descendents are bounded
by their ancestors. Then it's down to the reviewer or future developers
to figure out how the shell code handles that.
>
> Joerg
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2021-11-23 10:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 14:13 [LTP] [PATCH] cpuset_regression_test: Fix test, if cpuset groups exist already Joerg Vehlow
2021-11-22 15:09 ` Richard Palethorpe
2021-11-23 5:46 ` Joerg Vehlow
2021-11-23 9:46 ` Richard Palethorpe [this message]
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=8735nnm9au.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=joerg.vehlow@aox-tech.de \
--cc=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/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