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: <1631146225-13387-1-git-send-email-prakash.sangappa@oracle.com>
In-Reply-To: <1631146225-13387-1-git-send-email-prakash.sangappa@oracle.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Thu, 9 Sep 2021 10:42:43 -0700
Message-ID: <CALCETrVHf90pWD6YnE3DCOo2bw1StKGPvZMgFz9a08eWPK2pFg@mail.gmail.com>
Subject: Re: [RESEND RFC PATCH 0/3] Provide fast access to thread specific data
To:     Prakash Sangappa <prakash.sangappa@oracle.com>
Cc:     Linux API <linux-api@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Sep 8, 2021 at 5:02 PM Prakash Sangappa
<prakash.sangappa@oracle.com> wrote:
>
> 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.
>
> (patchset based on v5.14-rc7)
>
> Cover letter previously sent:
> ----------------------------
>
> Some applications, like a Databases require reading thread specific stats
> frequently from the kernel in latency sensitive codepath. The overhead of
> reading stats from kernel using system call affects performance.
> One use case is reading thread's scheduler stats from /proc schedstat file
> (/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.
>
> 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.


Can these use cases be addressed by creating a perf event
(perf_event_open) and mmapping it?