Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Joel Fernandes <joel@joelfernandes.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 00/11] Reviving the Proxy Execution Series
Date:   Wed, 19 Oct 2022 08:23:39 -0400
Message-Id: <F9BCD313-15BA-429C-B50C-1391DDC1239B@joelfernandes.org>
References: <20221019114357.yipijpetxz7ns5aq@airbuntu>
Cc:     Connor O'Brien <connoro@google.com>, linux-kernel@vger.kernel.org,
        kernel-team@android.com, John Stultz <jstultz@google.com>,
        Qais Yousef <qais.yousef@arm.com>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Will Deacon <will@kernel.org>,
        Waiman Long <longman@redhat.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        "Paul E . McKenney" <paulmck@kernel.org>
In-Reply-To: <20221019114357.yipijpetxz7ns5aq@airbuntu>
To:     Qais Yousef <qyousef@layalina.io>
Precedence: bulk


> On Oct 19, 2022, at 7:43 AM, Qais Yousef <qyousef@layalina.io> wrote:
>=20
> =EF=BB=BFOn 10/17/22 02:23, Joel Fernandes wrote:
>=20
>> I ran a test to check CFS time sharing. The accounting on top is confusin=
g,
>> but ftrace confirms the proxying happening.
>>=20
>> Task A - pid 122
>> Task B - pid 123
>> Task C - pid 121
>> Task D - pid 124
>>=20
>> Here D and B just spin all the time. C is lock owner (in-kernel mutex) an=
d
>> spins all the time, while A blocks on the same in-kernel mutex and remain=
s
>> blocked.
>>=20
>> Then I did "top -H" while the test was running which gives below output.
>> The first column is PID, and the third-last column is CPU percentage.
>>=20
>> Without PE:
>>  121 root      20   0   99496   4   0 R  33.6   0.0   0:02.76 t  (task C)=

>>  123 root      20   0   99496   4   0 R  33.2   0.0   0:02.75 t  (task B)=

>>  124 root      20   0   99496   4   0 R  33.2   0.0   0:02.75 t  (task D)=

>>=20
>> With PE:
>>  PID
>>  122 root      20   0   99496   4   0 D  25.3   0.0   0:22.21 t  (task A)=

>>  121 root      20   0   99496   4   0 R  25.0   0.0   0:22.20 t  (task C)=

>>  123 root      20   0   99496   4   0 R  25.0   0.0   0:22.20 t  (task B)=

>>  124 root      20   0   99496   4   0 R  25.0   0.0   0:22.20 t  (task D)=

>>=20
>> With PE, I was expecting 2 threads with 25% and 1 thread with 50%. Instea=
d I
>> get 4 threads with 25% in the top. Ftrace confirms that the D-state task i=
s
>> in fact not running and proxying to the owner task so everything seems
>> working correctly, but the accounting seems confusing, as in, it is confu=
sing
>> to see the D-state task task taking 25% CPU when it is obviously "sleepin=
g".
>>=20
>> Yeah, yeah, I know D is proxying for C (while being in the uninterruptibl=
e
>> sleep state), so may be it is OK then, but I did want to bring this up :-=
)
>=20
> I seem to remember Valentin raised similar issue about how userspace view c=
an
> get confusing/misleading:
>=20
>    https://www.youtube.com/watch?v=3DUQNOT20aCEg&t=3D3h21m41s

Thanks for the pointer! Glad to see the consensus was that this is not accep=
table.

I think we ought to write a patch to fix the accounting, for this series. I p=
ropose adding 2 new entries to proc/pid/stat which I think Juri was also sor=
t of was alluding to:

1. Donated time.
2. Proxied time.

User space can then add or subtract this, to calculate things correctly. Or j=
ust display them in new columns. I think it will also actually show how much=
 the proxying is happening for a use case.

Thoughts?

Thanks.


> Cheers
>=20
> --
> Qais Yousef