Thread (8 messages) flat view 8 messages, 3 authors, 2021-09-14

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

From: Jann Horn <jannh@google.com>
Date: 2021-09-10 19:12:40
Also in: lkml

On Fri, Sep 10, 2021 at 6:28 PM Peter Oskolkov [off-list ref] wrote:
On Fri, Sep 10, 2021 at 9:13 AM Prakash Sangappa
[off-list ref] wrote:
quoted
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...
That seems like it'll just create trouble a few years down the line
when the arbitrarily-chosen limit that nobody is monitoring blows up
in someone's production environment.

If this area is used for specific per-thread items, then the kernel
should be able to enforce that you only allocate as much space as is
needed for all threads of the process (based on the maximum number
that have ever been running in parallel in the process), right? Which
would probably work best if the kernel managed those allocations.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help