Re: [RESEND RFC PATCH 0/3] Provide fast access to thread specific data

On Fri, Sep 10, 2021 at 9:13 AM Prakash Sangappa
[off-list ref] wrote:

quoted

On Sep 10, 2021, at 8:18 AM, Peter Oskolkov [off-list ref] wrote:

On Wed, Sep 8, 2021 at 5:16 PM Prakash Sangappa
[off-list ref] wrote:

quoted

Including liunx-kernel..

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.

Hi Prakash,

quoted

I'd like to add here that Jann and I have been discussing a similar
feature for my UMCG patchset:

https://lore.kernel.org/lkml/CAG48ez0mgCXpXnqAUsa0TcFBPjrid-74Gj=xG8HZqj2n+OPoKw@mail.gmail.com/ (local)

Hi Peter,

I will take  a look.

quoted

In short, due to the need to read/write to the userspace from
non-sleepable contexts in the kernel it seems that we need to have some
form of per task/thread kernel/userspace shared memory that is pinned,
similar to what your sys_task_getshared does.

Exactly. For this reason wanted kernel to allocate the pinned memory.
Didn’t want to deal with files etc as a large number threads will be using
the shared structure mechanism.

quoted

Do you think your sys_task_getshared can be tweaked to return an
arbitrarily-sized block of memory (subject to overall constraints)
rather than a fixed number of "options"?

I suppose it could. How big of a size? We don’t want to hold on to
arbitrarily large  amount of pinned memory. The preference would
be for the kernel to decide what is going to be shared based on
what functionality/data sharing is supported. In that sense the size
is pre defined not something the userspace/application can ask.

There could be a sysctl or some other mechanism that limits the amount
of memory pinned per mm (or per task). Having "options" hardcoded for
such a generally useful feature seems limiting...

I have not looked at your use case.

quoted

On a more general note, we have a kernel extension internally at
Google, named "kuchannel", that is similar to what you propose here:
per task/thread shared memory with counters and other stat fields that
the kernel populates and the userspace reads (and some additional
functionality that is not too relevant to the discussion).

We have few other use cases for this we are looking at, which I can
describe later.

-Prakash

quoted

Thanks,
Peter

[...]