mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yunsheng Lin <linyunsheng@huawei.com>
To: David Miller <davem@davemloft.net>
Cc: <hkallweit1@gmail.com>, <f.fainelli@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linuxarm@huawei.com>
Subject: Re: [PATCH net-next] net: link_watch: prevent starvation when processing linkwatch wq
Date: Wed, 29 May 2019 16:59:13 +0800	[thread overview]
Message-ID: <6e9b41c9-6edb-be7f-07ee-5480162a227e@huawei.com> (raw)
In-Reply-To: <20190528.235806.323127882998745493.davem@davemloft.net>

On 2019/5/29 14:58, David Miller wrote:
> From: Yunsheng Lin <linyunsheng@huawei.com>
> Date: Mon, 27 May 2019 09:47:54 +0800
> 
>> When user has configured a large number of virtual netdev, such
>> as 4K vlans, the carrier on/off operation of the real netdev
>> will also cause it's virtual netdev's link state to be processed
>> in linkwatch. Currently, the processing is done in a work queue,
>> which may cause worker starvation problem for other work queue.
>>
>> This patch releases the cpu when link watch worker has processed
>> a fixed number of netdev' link watch event, and schedule the
>> work queue again when there is still link watch event remaining.
>>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> 
> Why not rtnl_unlock(); yield(); rtnl_lock(); every "100" events
> processed?
> 
> That seems better than adding all of this overhead to reschedule the
> workqueue every 100 items.

One minor concern, the above solution does not seem to solve the cpu
starvation for other normal workqueue which was scheduled on the same
cpu as linkwatch. Maybe I misunderstand the workqueue or there is other
consideration here? :)

Anyway, I will implemet it as you suggested and test it before posting V2.
Thanks.

> 
> .
> 


  reply	other threads:[~2019-05-29  8:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27  1:47 Yunsheng Lin
2019-05-27 14:58 ` Stephen Hemminger
2019-05-28  1:04   ` Yunsheng Lin
2019-05-28  1:17     ` Stephen Hemminger
2019-05-28  1:48       ` Yunsheng Lin
2019-05-29  8:12     ` Salil Mehta
2019-05-29  8:41       ` Yunsheng Lin
2019-05-29  6:58 ` David Miller
2019-05-29  8:59   ` Yunsheng Lin [this message]
2019-06-25  2:28     ` Yunsheng Lin
2019-06-27 18:17       ` David Miller

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=6e9b41c9-6edb-be7f-07ee-5480162a227e@huawei.com \
    --to=linyunsheng@huawei.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®