From: Marcelo Tosatti <mtosatti@redhat.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Frederic Weisbecker <frederic@kernel.org>,
Frederic Weisbecker <fweisbecker@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Leonardo Bras <leobras@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeelb@google.com>,
Muchun Song <muchun.song@linux.dev>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH 1/2] sched/isolation: Add cpu_is_isolated() API
Date: Thu, 30 Mar 2023 12:21:22 -0300 [thread overview]
Message-ID: <ZCWo8n88qWL0GmQ8@tpad> (raw)
In-Reply-To: <ZCWOlHmyO1YREEGt@dhcp22.suse.cz>
On Thu, Mar 30, 2023 at 03:28:52PM +0200, Michal Hocko wrote:
> > > Is this a best practice documented anywhere or it just happens to be
> > > the case with workloads you deal with?
> >
> > Option 2. However Frederic seems interested in matching the exported
> > toggles with the known use-cases classes.
> >
> > For example, for this guide:
> > http://www.comfilewiki.co.kr/en/doku.php?id=comfilepi:improving_real-time_performance:index
> >
> > Using nohz_full= would be a benefit (and its not being currently set,
> > perhaps due to not knowing all the options?).
> >
> > http://www.comfilewiki.co.kr/en/doku.php?id=comfilepi:improving_real-time_performance:index
> >
> >
> > AFAIU the workloads for which disabling nohz_full= is a benefit are those
> > where the switching between nohz full mode and sched tick enabled mode
> > and vice-versa (which involve programming the local timer) happens
> > often and is therefore avoidable? For example switching between 1
> > runnable task and more than 1 runnable task (and vice versa).
>
> The patch from Frederic is testing for both. You seem to be arguing to
> reduce the test and I still do not understand why. Sure some workloads
> (following the above) will likely use nohz_full= as well but does it
> make sense to build that expectation into the higher level logic? What
> is an actual benefit?
Just thinking of simpler code. Feel free to maintain the patch as-is if
you see fit.
next prev parent reply other threads:[~2023-03-30 18:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 13:44 [PATCH 0/2] memcg, cpuisol: do not interfere pcp cache charges draining with cpuisol workloads Michal Hocko
2023-03-17 13:44 ` [PATCH 1/2] sched/isolation: Add cpu_is_isolated() API Michal Hocko
2023-03-17 18:33 ` Marcelo Tosatti
2023-03-17 18:35 ` Marcelo Tosatti
2023-03-18 8:04 ` Michal Hocko
2023-03-24 22:35 ` Frederic Weisbecker
2023-03-27 10:24 ` Marcelo Tosatti
2023-03-28 11:38 ` Frederic Weisbecker
2023-03-28 11:48 ` Michal Hocko
2023-03-29 14:20 ` Marcelo Tosatti
2023-03-30 13:28 ` Michal Hocko
2023-03-30 15:21 ` Marcelo Tosatti [this message]
2023-03-17 13:44 ` [PATCH 2/2] memcg: do not drain charge pcp caches on remote isolated cpus Michal Hocko
2023-03-17 20:08 ` Shakeel Butt
2023-03-17 21:51 ` kernel test robot
2023-03-17 22:22 ` kernel test robot
2023-03-17 23:32 ` Andrew Morton
2023-03-18 8:03 ` Michal Hocko
2023-03-18 3:23 ` Hillf Danton
2023-03-18 8:08 ` Michal Hocko
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=ZCWo8n88qWL0GmQ8@tpad \
--to=mtosatti@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=frederic@kernel.org \
--cc=fweisbecker@suse.de \
--cc=hannes@cmpxchg.org \
--cc=leobras@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=peterz@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.