[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1561664970-1555-1-git-send-email-chiluk+linux@indeed.com>
Date: Thu, 27 Jun 2019 14:49:29 -0500
From: Dave Chiluk <chiluk+linux@...eed.com>
To: Ben Segall <bsegall@...gle.com>, Pqhil Auld <pauld@...hat.com>,
Peter Oskolkov <posk@...k.io>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, Brendan Gregg <bgregg@...flix.com>,
Kyle Anderson <kwa@...p.com>,
Gabriel Munos <gmunoz@...flix.com>,
John Hammond <jhammond@...eed.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: [PATCH v5 0/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
Changelog v5
- Based on this comment from Ben Segall's comment on v4
> If the cost of taking this global lock across all cpus without a
> ratelimit was somehow not a problem, I'd much prefer to just set
> min_cfs_rq_runtime = 0. (Assuming it is, I definitely prefer the "lie
> and sorta have 2x period 2x runtime" solution of removing expiration)
I'm resubmitting my v3 patchset, with the requested changes.
- Updated Commit log given review comments
- Update sched-bwc.txt give my new understanding of the slack timer.
Changelog v4
- Rewrote patchset around the concept of returning all of runtime_remaining
when cfs_b nears the end of available quota.
Changelog v3
- Reworked documentation to better describe behavior of slice expiration per
feedback from Peter Oskolkov
Changelog v2
- Fixed some checkpatch errors in the commit message.
Powered by blists - more mailing lists