[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231018111547.0be5532d@hermes.local>
Date: Wed, 18 Oct 2023 11:15:47 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Antoine Tenart <atenart@...nel.org>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
edumazet@...gle.com, netdev@...r.kernel.org, gregkh@...uxfoundation.org,
mhocko@...e.com
Subject: Re: [RFC PATCH net-next 0/4] net-sysfs: remove
rtnl_trylock/restart_syscall use
On Wed, 18 Oct 2023 17:47:42 +0200
Antoine Tenart <atenart@...nel.org> wrote:
> Some time ago we tried to improve the rtnl_trylock/restart_syscall
> situation[1]. What happens is when there is rtnl contention, userspace
> accessing net sysfs attributes will spin and experience delays. This can
> happen in different situations, when sysfs attributes are accessed
> (networking daemon, configuration, monitoring) while operations under
> rtnl are performed (veth creation, driver configuration, etc). A few
> improvements can be done in userspace to ease things, like using the
> netlink interface instead, or polling less (or more selectively) the
> attributes; but in the end the root cause is always there and this keeps
> happening from time to time.
What attribute is not exposed by netlink, and only by sysfs?
There will always be more overhead using sysfs.
That doesn't mean the locking should not be fixed, just that better
to avoid the situation if possible.
Powered by blists - more mailing lists