ill_cfs_bandwidth_runtime() does no longer update the
> expiration time, so fix the comments accordingly.
>
> Fixes: de53fd7aedb1 ("sched/fair: Fix low cpu usage with high throttling by
> removing expiration of cpu-local slices")
> Reviewed-by: Ben Segall
> Reviewed-by: Da
runtime(struct cfs_rq
> > *cfs_rq)
> >
> > void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
> > {
> > - u64 overrun;
> > -
> > lockdep_assert_held(_b->lock);
> >
> > if (cfs_b->period_active)
> >
Commit-ID: de53fd7aedb100f03e5d2231cfce0e4993282425
Gitweb: https://git.kernel.org/tip/de53fd7aedb100f03e5d2231cfce0e4993282425
Author: Dave Chiluk
AuthorDate: Tue, 23 Jul 2019 11:44:26 -0500
Committer: Peter Zijlstra
CommitDate: Thu, 8 Aug 2019 09:09:30 +0200
sched/fair: Fix low cpu
uota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk
---
Documentation/scheduler/sched-bwc.txt | 73 ---
On Mon, Jun 24, 2019 at 10:33:07AM -0700, bseg...@google.com wrote:
> This still has a similar cost as reducing min_cfs_rq_runtime to 0 - we
> now take a tg-global lock on every group se dequeue. Setting min=0 means
> that we have to take it on both enqueue and dequeue, while baseline
> means we
nears the sched_cfs_bandwidth_slice. This balances the
desire to prevent cfs_rq from always pulling quota with the desire to
allow applications to fully utilize their quota.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk
---
kernel/sched/fair.c | 19 ++
Changelog v4
- Rewrote patch to return all quota when cfs_b has very litte.
- Removed documentation changes, as bursting is no longer possible with this
new solution.
After the suggestion from Ben Segall to set min_cfs_rq_runtime=0, I came up
this in an attempt to balance the desire leave
On Wed, May 29, 2019 at 02:05:55PM -0700, bseg...@google.com wrote:
> Dave Chiluk writes:
>
> Yeah, having run the test, stranding only 1 ms per cpu rather than 5
> doesn't help if you only have 10 ms of quota and even 10 threads/cpus.
> The slack timer isn't important in this
e consumed every period.
Your review would be much appreciated.
Thank you,
Dave
On Wed, Apr 10, 2019 at 5:21 PM Dave Chiluk wrote:
>
> It has been observed, that highly-threaded, non-cpu-bound applications
> running under cpu.cfs_quota_us constraints can hit a high percentage of
> p
x performance improvement,
while still maintaining correct cpu quota restrictions albeit over
longer time intervals than cpu.cfs_period_us.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: D
The following patch is an implementation of option 2 from my earlier e-mail.
Option #2 was the removal of all runtime_expires and related slice expiration
logic.
This is a very early iteration of this patch, and testing/comments are very
appreciated.
Thanks,
Dave.
xperience when you ask for .5 cpu, and are only able to
use .1 of it while being throttled because of time slice expiration.
Thank you,
Dave Chiluk
p.s. I've copied representatives of Netflix and Yelp as well, as we
were talking about this at the Scale 17x conference. There we
discovered we ha
Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.
Signed-off-by: Dave Chiluk
---
Documentation/stable_kernel_rules.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation
Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.
Signed-off-by: Dave Chiluk chi...@canonical.com
---
Documentation/stable_kernel_rules.txt | 3 +++
1 file changed, 3 insertions(+)
diff
Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.
Signed-off-by: Dave Chiluk
---
Documentation/stable_kernel_rules.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation
Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.
Signed-off-by: Dave Chiluk
---
Documentation/stable_kernel_rules.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation
Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.
Signed-off-by: Dave Chiluk chi...@canonical.com
---
Documentation/stable_kernel_rules.txt | 3 +++
1 file changed, 3 insertions(+)
diff
Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.
Signed-off-by: Dave Chiluk chi...@canonical.com
---
Documentation/stable_kernel_rules.txt | 3 +++
1 file changed, 3 insertions(+)
diff
On 06/11/2014 03:46 PM, Eric W. Biederman wrote:
> ip netns add also performs a bind mount so we get into all of the vfs
> level locking as well.
It's actually quite a bit worse than that as ip netns exec creates a new
mount namespace as well. That being said, the vfs issues have been
healthily
On 06/11/2014 11:18 AM, Paul E. McKenney wrote:
> On Wed, Jun 11, 2014 at 10:46:00AM -0500, David Chiluk wrote:
>> Now think about what happens when a gateway goes down, the namespaces
>> need to be migrated, or a new machine needs to be brought up to replace
>> it. When we're talking about 3000
On 06/11/2014 11:18 AM, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 10:46:00AM -0500, David Chiluk wrote:
Now think about what happens when a gateway goes down, the namespaces
need to be migrated, or a new machine needs to be brought up to replace
it. When we're talking about 3000
On 06/11/2014 03:46 PM, Eric W. Biederman wrote:
ip netns add also performs a bind mount so we get into all of the vfs
level locking as well.
It's actually quite a bit worse than that as ip netns exec creates a new
mount namespace as well. That being said, the vfs issues have been
healthily
On 07/15/2013 05:38 PM, Linus Torvalds wrote:
> A small panel discussion with a few people (fiveish?) that have very
> different viewpoints, along with baskets of rotten fruit set out on
> the tables?
As I think the purpose of this discussion was to improve linux by
attracting and growing new
On 07/15/2013 05:38 PM, Linus Torvalds wrote:
A small panel discussion with a few people (fiveish?) that have very
different viewpoints, along with baskets of rotten fruit set out on
the tables?
As I think the purpose of this discussion was to improve linux by
attracting and growing new
Running the below testcase shows each process consuming 41-43% of it's
respective cpu while per core idle numbers show 63-65%, a disparity of
roughly 4-8%. Is this a bug, known behaviour, or consequence of the
process being io bound?
1. run sudo taskset -c 0 netserver
2. run taskset -c 1 netperf
Running the below testcase shows each process consuming 41-43% of it's
respective cpu while per core idle numbers show 63-65%, a disparity of
roughly 4-8%. Is this a bug, known behaviour, or consequence of the
process being io bound?
1. run sudo taskset -c 0 netserver
2. run taskset -c 1 netperf
On 06/13/2013 01:42 AM, Al Viro wrote:
> On Thu, Jun 13, 2013 at 03:01:22AM +0100, Al Viro wrote:
>> On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
>>> On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
>>>> Can't you just use the patch from
On 06/12/2013 09:01 PM, Al Viro wrote:
> On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
>> On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
>>> Can't you just use the patch from my original e-mail? Anyhow I attached
>>> it an already signed-off pat
On 06/12/2013 09:01 PM, Al Viro wrote:
On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
Can't you just use the patch from my original e-mail? Anyhow I attached
it an already signed-off patch.
Al Viro Can you integrate
On 06/13/2013 01:42 AM, Al Viro wrote:
On Thu, Jun 13, 2013 at 03:01:22AM +0100, Al Viro wrote:
On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
Can't you just use the patch from my original e-mail? Anyhow I attached
Can't you just use the patch from my original e-mail? Anyhow I attached
it an already signed-off patch.
Al Viro Can you integrate it now?
Dave.
On 06/07/2013 01:43 AM, Petr Vandrovec wrote:
> On Wed, Jun 5, 2013 at 1:20 PM, Dave Chiluk wrote:
>> Petr do you still have commit rights
Can't you just use the patch from my original e-mail? Anyhow I attached
it an already signed-off patch.
Al Viro Can you integrate it now?
Dave.
On 06/07/2013 01:43 AM, Petr Vandrovec wrote:
On Wed, Jun 5, 2013 at 1:20 PM, Dave Chiluk chi...@canonical.com wrote:
Petr do you still have commit
intainership for it anymore :-(
>
> Petr
>
> On May 31, 2013 2:40 PM, "Dave Chiluk" <mailto:chi...@canonical.com>> wrote:
>
> Any thoughts on this? NCPFS seems to be the forgotten, left-behind,
> red-headed stepchild of the fs community.
>
&
for it anymore :-(
Petr
On May 31, 2013 2:40 PM, Dave Chiluk chi...@canonical.com
mailto:chi...@canonical.com wrote:
Any thoughts on this? NCPFS seems to be the forgotten, left-behind,
red-headed stepchild of the fs community.
Dave.
On 05/28/2013 05:50 PM, Dave Chiluk
Any thoughts on this? NCPFS seems to be the forgotten, left-behind,
red-headed stepchild of the fs community.
Dave.
On 05/28/2013 05:50 PM, Dave Chiluk wrote:
> 1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such
> that
> directories could no longer b
Any thoughts on this? NCPFS seems to be the forgotten, left-behind,
red-headed stepchild of the fs community.
Dave.
On 05/28/2013 05:50 PM, Dave Chiluk wrote:
1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such
that
directories could no longer be removed
1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that
directories could no longer be removed. This was because ncp_rmdir checked
to see if a dentry could be unhashed before allowing it to be removed. Since
1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that
1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that
directories could no longer be removed. This was because ncp_rmdir checked
to see if a dentry could be unhashed before allowing it to be removed. Since
1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that
Rmdir and or rm -rf are failing on an ncpfs mounted directory.
for example
root@precise:/mnt/ncp# mkdir a ; rmdir a
rmdir: failed to remove `a': Device or resource busy
I bisected the change that introduced the regression to .
commit 1d2ef5901483004d74947bbf78d5146c24038fe7 which follows.
Rmdir and or rm -rf are failing on an ncpfs mounted directory.
for example
root@precise:/mnt/ncp# mkdir a ; rmdir a
rmdir: failed to remove `a': Device or resource busy
I bisected the change that introduced the regression to .
commit 1d2ef5901483004d74947bbf78d5146c24038fe7 which follows.
diff
On 04/24/2013 04:28 PM, Myklebust, Trond wrote:
> On Wed, 2013-04-24 at 15:55 -0500, Dave Chiluk wrote:
>> Changing the retry to start at NFS4_POLL_RETRY_MIN and exponentially grow
>> to NFS4_POLL_RETRY_MAX allow for faster handling of these error conditions.
>>
>> A
, on a
close when it happens in close proximity to a RELEASE_LOCKOWNER. This would
cause a linux client to hang for 15 seconds.
Signed-off-by: Dave Chiluk
---
fs/nfs/nfs4proc.c| 12
include/linux/sunrpc/sched.h |1 +
2 files changed, 13 insertions(+)
diff --git a/fs
, on a
close when it happens in close proximity to a RELEASE_LOCKOWNER. This would
cause a linux client to hang for 15 seconds.
Signed-off-by: Dave Chiluk chi...@canonical.com
---
fs/nfs/nfs4proc.c| 12
include/linux/sunrpc/sched.h |1 +
2 files changed, 13 insertions
On 04/24/2013 04:28 PM, Myklebust, Trond wrote:
On Wed, 2013-04-24 at 15:55 -0500, Dave Chiluk wrote:
Changing the retry to start at NFS4_POLL_RETRY_MIN and exponentially grow
to NFS4_POLL_RETRY_MAX allow for faster handling of these error conditions.
Additionally this alleviates
).
This fixes inability to chown on chgrp files on AIX nfs shares.
Reported-by: Dave Chiluk
Signed-off-by: Trond Myklebust
Cc: Bryan Schumaker
Cc: sta...@vger.kernel.org [>=3.4]
---
fs/nfs/idmap.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/nfs/idmap.c b/fs/
in the keyring).
This fixes inability to chown on chgrp files on AIX nfs shares.
Reported-by: Dave Chiluk dave.chi...@canonical.com
Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com
Cc: Bryan Schumaker bjsch...@netapp.com
Cc: sta...@vger.kernel.org [=3.4]
---
fs/nfs/idmap.c | 14
On 02/28/2013 10:47 AM, Jeff Layton wrote:
> On Thu, 28 Feb 2013 10:04:36 -0600
> Steve French wrote:
>
>> On Thu, Feb 28, 2013 at 9:26 AM, Jeff Layton wrote:
>>> On Wed, 27 Feb 2013 16:24:07 -0600
>>> Dave Chiluk wrote:
>>>
>>>> On 02/27/
On 02/28/2013 10:47 AM, Jeff Layton wrote:
On Thu, 28 Feb 2013 10:04:36 -0600
Steve French smfre...@gmail.com wrote:
On Thu, Feb 28, 2013 at 9:26 AM, Jeff Layton jlay...@samba.org wrote:
On Wed, 27 Feb 2013 16:24:07 -0600
Dave Chiluk dave.chi...@canonical.com wrote:
On 02/27/2013 10:34 AM
On 02/27/2013 04:40 PM, Steve French wrote:
> On Wed, Feb 27, 2013 at 4:24 PM, Dave Chiluk
> wrote:
>> On 02/27/2013 10:34 AM, Jeff Layton wrote:
>>> On Wed, 27 Feb 2013 12:06:14 +0100
>>> "Stefan (metze) Metzmacher" wrote:
>>>
>>>
On 02/27/2013 10:34 AM, Jeff Layton wrote:
> On Wed, 27 Feb 2013 12:06:14 +0100
> "Stefan (metze) Metzmacher" wrote:
>
>> Hi Dave,
>>
>>> When messages are currently in queue awaiting a response, decrease amount of
>>> time before attempting cifs_reconnect to SMB_MAX_RTT = 10 seconds. The
>>>
On 02/27/2013 10:34 AM, Jeff Layton wrote:
On Wed, 27 Feb 2013 12:06:14 +0100
Stefan (metze) Metzmacher me...@samba.org wrote:
Hi Dave,
When messages are currently in queue awaiting a response, decrease amount of
time before attempting cifs_reconnect to SMB_MAX_RTT = 10 seconds. The
On 02/27/2013 04:40 PM, Steve French wrote:
On Wed, Feb 27, 2013 at 4:24 PM, Dave Chiluk dave.chi...@canonical.com
wrote:
On 02/27/2013 10:34 AM, Jeff Layton wrote:
On Wed, 27 Feb 2013 12:06:14 +0100
Stefan (metze) Metzmacher me...@samba.org wrote:
Hi Dave,
When messages are currently
reconnect sooner. However in the best
case where the user changes nics, and immediately tries to access the cifs
share it will take SMB_MAX_RTT=10 seconds.
BugLink: http://bugs.launchpad.net/bugs/1017622
Signed-off-by: Dave Chiluk
---
fs/cifs/cifsglob.h | 15 +++--
fs/cifs/connect.c | 61
reconnect sooner. However in the best
case where the user changes nics, and immediately tries to access the cifs
share it will take SMB_MAX_RTT=10 seconds.
BugLink: http://bugs.launchpad.net/bugs/1017622
Signed-off-by: Dave Chiluk chi...@canonical.com
---
fs/cifs/cifsglob.h | 15 +++--
fs
54 matches
Mail list logo
