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;
From:   Prakash Sangappa <prakash.sangappa@oracle.com>
To:     Andy Lutomirski <luto@kernel.org>
CC:     Linux API <linux-api@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND RFC PATCH 0/3] Provide fast access to thread specific
 data
Thread-Topic: [RESEND RFC PATCH 0/3] Provide fast access to thread specific
 data
Thread-Index: AQHXpQ4DkHk4xUSqc0e/8XETIulFxqub+hOAgAfWpgA=
Date:   Tue, 14 Sep 2021 17:24:49 +0000
Message-ID: <4A2A9989-F407-4D5D-A9ED-C82EF3E8103E@oracle.com>
References: <1631146225-13387-1-git-send-email-prakash.sangappa@oracle.com>
 <CALCETrVHf90pWD6YnE3DCOo2bw1StKGPvZMgFz9a08eWPK2pFg@mail.gmail.com>
In-Reply-To: <CALCETrVHf90pWD6YnE3DCOo2bw1StKGPvZMgFz9a08eWPK2pFg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?cqTpRxt7SoEuC+uaKyWBKENHBwOWjK1zrzzyRmzhgubHPB79SKb7aHPlkAEA?=
 =?us-ascii?Q?KvirzBBUoHFbxF3AXRhDWCo7Q8Dlf7ddvQGPpNfapWkhdh2rzyebP+r/m7Ja?=
 =?us-ascii?Q?YkPtjOHL6glUjIFwKqMuQr+VzuctUGKV/rSEtSPdeJU1Qpi2XmrnwZVm9mJY?=
 =?us-ascii?Q?ZRe1zbNhu+FAkqHRMcrcuqs4qCjCw3j9WDurCluxnvN6TYsT2SJhfGhOfIMc?=
 =?us-ascii?Q?IgqGpvp/KWvDjoAQOqUosL7nalGY8uW5lxMB076zjYQ1Rl7u4MYqARn1HLiZ?=
 =?us-ascii?Q?BGo++GXTeutFY7Bdc5POiNbVm2huF5o5MhoOkv32MQg4U+RLYC6hvtqLfl5i?=
 =?us-ascii?Q?/iufivpbyePCKY/fqTDc7mX9Ks5xdIq1WbdZ/rs0IybKfn8whf6z56bPPxdb?=
 =?us-ascii?Q?ntM8eHcLsRRPi/8cLsvczL94y4DanvEjRTsoeYCZ29cQnGveTQ/KTaf2Sx3P?=
 =?us-ascii?Q?nX/3vYV4NHt3MYs+9Qy+Elu/9k2mJ/GLIQKd3rS23t12GTkB/Wgo9yngXQoX?=
 =?us-ascii?Q?X23kuKZSiMvTCfNfPYnmaVXS+TNl85lwuQCizVpyT1rhiOnamZLpHvhrRdKK?=
 =?us-ascii?Q?oU9sAXibMbVGbCtHP0WcgvuEpB6WqLxY520fWEE8SKi8I1oHbOzbGo7LOmnI?=
 =?us-ascii?Q?v8QQD3TBJmDYOU8tuEIWsOWPg9pAUmfEyh9gi3ceffhXGKraxA+DkLB9h1eI?=
 =?us-ascii?Q?Pp38vvVDEsN+zjsEdhJ9mkFqejjGhVv2JSkm2MP9jAeluSAKwZXLJgjA9YwJ?=
 =?us-ascii?Q?cemdPDMS1uzVWSKKekENEGZNX3PsW6IaOphs1klB3Jd32xJZAbrlUqfZte0e?=
 =?us-ascii?Q?tK7YLbIPilgoQb6e0VX63ttPiYPzyUZGRhtfxPsLryvVaF6j5L/hJKEMTyLh?=
 =?us-ascii?Q?uyPwQt3AUhftw8FCDq5gg7kIpzq+udODFNYcG3+18GoIGdOUEUWNpvX/JWdR?=
 =?us-ascii?Q?PWXvFQ58X/mqxvJuuE5PlNJGubx/0CCN1osiSnXnTWtKEfKrdBfwGoow64A1?=
 =?us-ascii?Q?jUwHZNpk8HD64DOplAkZvxrHFRfLKXjnRaERdLMfGZfe9tVbnyhc6B2XWG+P?=
 =?us-ascii?Q?FJzbCnR2PlbQHzdah7UcdWns5k7WRi7A4ugOp4ktvj2K2OzDdKd7/IXtv5AN?=
 =?us-ascii?Q?mMk4ykw9gRwm45wleEQE3en+nhoMnKPunOsdJDj0aohwFN+xTRE3v8hyTuWG?=
 =?us-ascii?Q?NrXIhM/EQQsgDhPxA86oodUhKwggla5k/UOe3AHXynMcCTjvw0JeJOv0LUkU?=
 =?us-ascii?Q?M0Vdy/648tKZUaHK95gOLSZ9Un2mTI0Q5IQVuxTototBEVmvWRSNjEqOpy9o?=
 =?us-ascii?Q?AD7Xa9VqBVZmfHww6Da2mJtjC4JwdcgUCXJUbmLbPsRZtBUs0k2hjbgwBSAO?=
 =?us-ascii?Q?cW7pwBM=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EC18DB45FCEF8744BD1633FBB6C87CFC@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2629.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 63a8498a-bb3e-43a2-01c8-08d977a48e35
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2021 17:24:49.2447
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: x4zZomTtJG6SRf/TCAMo/1OBNh8WF0CE3C6Y+IrFbjy4OPXJ4rX05LcBu90Qt1vmBG/kflWjMR9V8NyAML47JNj9iyxyXSekY/e7Yqv1K5w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4557
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10107 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0
 mlxlogscore=999 adultscore=0 bulkscore=0 spamscore=0 phishscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2109030001 definitions=main-2109140100
X-Proofpoint-GUID: DV07fmSUR9apCZD6ow6163QIyPbwdltG
X-Proofpoint-ORIG-GUID: DV07fmSUR9apCZD6ow6163QIyPbwdltG
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Sep 9, 2021, at 10:42 AM, Andy Lutomirski <luto@kernel.org> wrote:
>=20
> On Wed, Sep 8, 2021 at 5:02 PM Prakash Sangappa
> <prakash.sangappa@oracle.com> wrote:
>>=20
>> Resending RFC. This patchset is not final. I am looking for feedback on
>> this proposal to share thread specific data for us in latency sensitive
>> codepath.
>>=20
>> (patchset based on v5.14-rc7)
>>=20
>> Cover letter previously sent:
>> ----------------------------
>>=20
>> Some applications, like a Databases require reading thread specific stat=
s
>> frequently from the kernel in latency sensitive codepath. The overhead o=
f
>> reading stats from kernel using system call affects performance.
>> One use case is reading thread's scheduler stats from /proc schedstat fi=
le
>> (/proc/pid/schedstat) to collect time spent by a thread executing on the
>> cpu(sum_exec_runtime), time blocked waiting on runq(run_delay). These
>> scheduler stats, read several times per transaction in latency-sensitive
>> codepath, are used to measure time taken by DB operations.
>>=20
>> This patch proposes to introduce a mechanism for kernel to share thread
>> stats thru a per thread shared structure shared between userspace and
>> kernel. The per thread shared structure is allocated on a page shared
>> mapped between user space and kernel, which will provide a way for fast
>> communication between user and kernel. Kernel publishes stats in this
>> shared structure. Application thread can read from it in user space
>> without requiring system calls.
>=20
>=20
> Can these use cases be addressed by creating a perf event
> (perf_event_open) and mmapping it?


As I understand these will be sampling based used for profiling? So will no=
t=20
be suitable for the use case we are looking at.=20

Also, it would require every thread to open and create perf event mappings.=
=20
Not sure how well this would scale given the requirement Is for use by a la=
rge=20
number of threads.=20

The proposal here is to provision a per thread shared memory space(between=
=20
userspace and kernel) with a small memory footprint as it needs to be alloc=
ated
from pinned memory, to share thread specific info, like per thread sched st=
ats
here. This should have low overhead and scale better.=20