On Mon, Mar 14, 2022 at 06:00:04PM -0400, John Kacur wrote:
>
>
> On Mon, 14 Mar 2022, Leah Leshchinsky wrote:
>
> > On Mon, Mar 14, 2022 at 01:01:59PM -0400, John Kacur wrote:
> > >
> > >
> > > On Thu, 10 Mar 2022, Leah Leshchinsky wrote:
> > >
> > > > On Thu, Mar 10, 2022 at 12:17:36PM -0500, John Kacur wrote:
> > > > >
> > > > >
> > > > > On Wed, 9 Mar 2022, Leah Leshchinsky wrote:
> > > > >
> > > > > > These patches introduce a new command-line interface that
provides
> > > > > > distinct subcommands for the user.
> > > > > > Through the use of argparse, users see simpler help menus
and can
> > > > > > view positional and optional arguments for all tuna
commands.
> > > > > > The internal implementation is also simplified by removing
the need
> > > > > > for a saved state for each iteration of parsing.
> > > > > >
> > > > > > v2 Removes unnecessary sample.py file added in previous
version,
> > > > > > moves changes to show_irqs() from patch 1/3 to 3/3.
> > > > > >
> > > > > > Leah Leshchinsky (3):
> > > > > > tuna: Update command-line interface
> > > > > > tuna: Edit param variable to print full policy name
> > > > > > tuna: Remove unused functions and globals
> > > > > >
> > > > > > tuna-cmd.py | 633
++++++++++++++++++++-------------------------------
> > > > > > tuna/tuna.py | 7 +-
> > > > > > 2 files changed, 246 insertions(+), 394 deletions(-)
> > > > > >
> > > > >
> > > > > This is a welcome change, thanks!
> > > > >
> > > > > Some initial comments from running this without looking at the
code.
> > > > >
> > > > > /tuna-cmd.py -h
> > > > > usage: tuna-cmd.py [-h] [-v]
> > > > >
> > > > >
{isolate,include,move,spread,priority,run,save,apply,show,what_is,gui}
> > > > > ...
> > > > >
> > > > > tuna - Application Tuning GUI
> > > > >
> > > > > subcommands:
> > > > >
{isolate,include,move,spread,priority,run,save,apply,show,what_is,gui}
> > > > > isolate Allow all threads to run on CPU-LIST
> > > > > include Allow all threads to run on CPU-LIST
> > > > > move Move selected entities to CPU-LIST
> > > > > spread Spread selected entities over CPU-LIST
> > > > > priority Set thread scheduler tunables: POLICY
and RTPRIO
> > > > > run fork a new process and run the COMMAND
> > > > > save Save kthreads sched tunables to
FILENAME
> > > > > apply Apply changes described in profile
> > > > > show Show a list for given SUBCOMMAND
> > > > > what_is Provides help about selected entities
> > > > > gui Start the GUI
> > > > >
> > > > > options:
> > > > > -h, --help show this help message and exit
> > > > > -v, --version show version
> > > > >
> > > > > In the above the same message appears next to isolate and
include.
> > > > > isolate should say, "Move all allowed threads and IRQs away
from CPU-LIST"
> > > > >
> > > > > For include, don't forget to add the words "all
allowed", this is
> > > > > important.
> > > > >
> > > > > When I run help on the commands, I only get usage and options,
I'd like to
> > > > > see a little more information, or at least a repeat of the above
lines.
> > > > > (look at rhpkg, or fedpkg as an example)
> > > > >
> > > > > I know I suggested "subcommands" because that's
what we call them in
> > > > > python argparse but from a user perspective, I think
"Commands" makes
> > > > > more sense.
> > > > >
> > > > > There appears to be missing functionality. Are you planning on
adding that
> > > > > in the future?
> > > > >
> > > > > For example, current tuna has -G Display the processes with the
type of
> > > > > cgroups they are in, which could be added to the show command.
> > > > >
> > > > > Also, current tuna allows you to specify that operations apply
only to
> > > > > kthreads or only to uthreads that could be added to a few
commands as
> > > > > well.
> > > > >
> > > > > After you make a few more changes (I need to look a bit more
closely at
> > > > > the implementation and comment there as well) I'll put this
in a separate
> > > > > branch, but I don't think it needs to live there very long,
I'd like to
> > > > > integrate this relatively soon.
> > > > >
> > > > > Thanks
> > > > >
> > > > > John
> > > > >
> > > >
> > > > Hi John,
> > > >
> > > > Thank you for the review.
> > > > I will make the necessary changes to the usage menus.
> > > > The functionality for options like -D to display cgroups,
> > > > and filtering by kthreads/uthreads is actually implemented
> > > > and can be viewed by commands such as "tuna show threads
-h",
> > > > but I will add a note on the help menus to make it clearer
> > > > to users that these optionals exist.
> > > >
> > > > Best,
> > > > Leah
> > >
> > > Hmnn, that is cool in a way, however I think one level of commands is
> > > enough, otherwise that interface is confusing for users.
> > >
> > > Here is my suggestion for tuna show
> > > separate "config" as a separate command for processing configs.
> > >
> > > with no arguments
> > > tuna config
> > > lists preloaded files like current tuna with -l
> > >
> > > tuna config -a PROFILENAME
> > > applies the profile without printing the preloaded files
> > >
> > > Then for the tuna show command irqs and threads should be options
> > > and it should be possible to have both options at the same time.
> > > Something like this
> > > tuna show [-h] [-P] [--show_threads] [-Q] [--show_irqs]
> > >
> > > so it would be possible to do
> > > tuna show -P -Q
> > > to get a list of threads and irqs at the same time.
> > >
> > > There still is some missing functionality, I think you need to go through
> > > old tuna and reaudit what it can do. I know you are simplifying somethings
> > > on purpose, because they were too complicated, but other things we
don't
> > > want to omit.
> > >
> > > For example sockets. Sockets is an overloaded word, so that can be
> > > confusing, but I'm talking about cpu sockets here. If you have a
machine
> > > with multiple cpu sockets you should be able to limit the output to the
> > > sockets you are interested in. For example
> > > tuna show [-h] [-P] [--show_threads] [-Q] [--show_irqs] [-S
> > > CPU_SOCKET_NUM]
> > >
> > > and the user can do tuna show -P -Q -S1
> > > to see only socket 1 if available.
> > >
> > > When it comes to things like -S that we find missing as we go over the
> > > code, it's okay to add that in pieces, that doesn't have to be
done all at
> > > once, so we can put that in latter patches. Be careful about deleting
> > > functions prematurely though that we still might need.
> > >
> > > Thanks
> > >
> > > John
> > > _______________________________________________
> > > tuna-devel mailing list -- tuna-devel(a)lists.fedorahosted.org
> > > To unsubscribe send an email to tuna-devel-leave(a)lists.fedorahosted.org
> > > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
https://lists.fedorahosted.org/archives/list/tuna-devel@lists.fedorahoste...
> > > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> >
> > Hi John,
> >
> > I believe the socket functionality is available, but it depends on
'have_inet_diag' evaluating to true.
> > This is to stay faithful to the original implementation of tuna, which conceals
the '--show_sockets' option
> > on systems that do not support it. I can see how this can be confusing and
prevent a user from understanding
> > what functionality is available in the tool. Do you have any suggestions for
how to implement this features
> > in such a way that it is clear to the user that it exists, but prevents the use
of the argument when it cannot
> > be supported? Perhaps a simple warning message will do?
> >
> > Best,
> > Leah
>
> As I was saying, sockets is an overloaded term. I'm not referring to
> network sockets. (that's what the inet stuff is). I'm referring to
> physical cpu sockets. You need to examine current tuna tuna-cmd.py next to
> your tuna-cmd.py, and run them side by side. Because the terms are
> overloaded, it can be confusing, so you have to read the code to
> understand which one tuna is dealing with.
>
> Tuna gets information about the cpu sockets from sysfs (part of
> python-linux-procfs), in current tuna search for -S, and this
> cpu_info = sysfs.cpus()
> This has been dropped from your code, but it would not be difficult to add
> it back.
>
> Thanks
>
> John
Hi John,
I see what you're saying now. You're right, I missed the cpu-socket option.
Should the --sockets argument be available for all commands that take the --cpus
argument?
Best,
Leah