On Fri, Dec 04, 2020 at 07:42:56AM +0200, Julian Anastasov wrote:
>
> Hello,
>
>On Fri, 4 Dec 2020, dust.li wrote:
>
>>
>> On 12/3/20 4:48 PM, Julian Anastasov wrote:
>> >
>> > - work will use spin_lock_bh(&s->lock) to protect the
>> > entries, we do not want delays between /proc readers and
Hello,
On Fri, 4 Dec 2020, dust.li wrote:
>
> On 12/3/20 4:48 PM, Julian Anastasov wrote:
> >
> > - work will use spin_lock_bh(&s->lock) to protect the
> > entries, we do not want delays between /proc readers and
> > the work if using mutex. But _bh locks stop timers and
> > networking
On 12/3/20 4:48 PM, Julian Anastasov wrote:
Hello,
On Thu, 3 Dec 2020, dust.li wrote:
Hi Yunhong & Julian, any updates ?
We've encountered the same problem. With lots of ipvs
services plus many CPUs, it's easy to reproduce this issue.
I have a simple script to reproduce:
First a
Hello,
On Thu, 3 Dec 2020, dust.li wrote:
> Hi Yunhong & Julian, any updates ?
>
>
> We've encountered the same problem. With lots of ipvs
>
> services plus many CPUs, it's easy to reproduce this issue.
>
> I have a simple script to reproduce:
>
> First add many ipvs services:
>
>
Hi Yunhong & Julian, any updates ?
We've encountered the same problem. With lots of ipvs
services plus many CPUs, it's easy to reproduce this issue.
I have a simple script to reproduce:
First add many ipvs services:
for((i=0;i<5;i++)); do
ipvsadm -A -t 10.10.10.10:$((2000+$i))
do
