Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1595601083-10183-1-git-send-email-qianjun.kernel@gmail.com>
 <87sgddaru7.fsf@nanos.tec.linutronix.de> <CAKc596+vF4eYa4h55P2cssQbRKqBV_-9c_v35SXVMdonP3HBHA@mail.gmail.com>
 <87v9i6a53n.fsf@nanos.tec.linutronix.de>
In-Reply-To: <87v9i6a53n.fsf@nanos.tec.linutronix.de>
From:   jun qian <qianjun.kernel@gmail.com>
Date:   Wed, 9 Sep 2020 16:32:10 +0800
Message-ID: <CAKc596+=k1kBffQfd=tPJGTtG_NinwSyqOXpCaPr1m8Xy3CG1g@mail.gmail.com>
Subject: Re: [PATCH V4] Softirq:avoid large sched delay from the pending softirqs
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     peterz@infradead.org, will@kernel.org, luto@kernel.org,
        linux-kernel@vger.kernel.org, Yafang Shao <laoar.shao@gmail.com>,
        Uladzislau Rezki <urezki@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Thomas Gleixner <tglx@linutronix.de> =E4=BA=8E2020=E5=B9=B47=E6=9C=8829=E6=
=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=888:16=E5=86=99=E9=81=93=EF=BC=9A
>
> Qian,
>
> jun qian <qianjun.kernel@gmail.com> writes:
> > On Mon, Jul 27, 2020 at 11:41 PM Thomas Gleixner <tglx@linutronix.de> w=
rote:
> >> > +                     or_softirq_pending(pending << (vec_nr + 1));
> >>
> >> To or the value interrupts need to be disabled because otherwise you c=
an
> >> lose a bit when an interrupt happens in the middle of the RMW operatio=
n
> >> and raises a softirq which is not in @pending and not in the per CPU
> >> local softirq pending storage.
> >>
> > I can't understand the problem described above, could you explain in
> > detail.
>
> Oring a value to a memory location is a Read Modify Write (RMW)
> operation.
>
>         x |=3D a;
>
> translates to pseudo code:
>
>         R1 =3D  x      // Load content of memory location x into register=
 R1
>         R1 |=3D a      // Or value a on R1
>         x =3D R1       // Write back result
>
> So assume:
>
>    x =3D 0
>    a =3D 1
>
>    R1 =3D x  --> R1 =3D=3D 0
>    R1 |=3D a --> R1 =3D=3D 1
>
> interrupt sets bit 1 in x       --> x =3D=3D 0x02
>
>    x =3D R1  --> x =3D=3D 1
>
> So you lost the set bit 1, right? Not really what you want.
>
> >> There is another problem. Assume bit 0 and 1 are pending when the
> >> processing starts. Now it breaks out after bit 0 has been handled and
> >> stores back bit 1 as pending. Before ksoftirqd runs bit 0 gets raised
> >> again. ksoftirqd runs and handles bit 0, which takes more than the
> >> timeout. As a result the bit 0 processing can starve all other softirq=
s.
> >>
> > May I use a percpu val to record the order of processing softirq, by th=
e order
> > val, when it is in ksoftirqd we can process the pending softirq in orde=
r. In the
> > scenario you described above, before ksoftirqd runs, bit 0 gets raised =
again,
> > ksoftirqd runs and handles bit 1 by the percpu val. just like a ring.
>
> Yes, you need something to save information about the not-processed
> bits. Keeping track of which bit to process next works, but whether
> that's going to result in efficient and simple code is a different
> question.
>
> Thanks,
>
>         tglx
>

Hi  Thomas, I am so sorry,   For personal reasons, the modification of
this patch was delayed, I will submit the next modified version in
these two days, sorry again