Thomas Gleixner writes:
> On Wed, Mar 10 2021 at 15:57, Eric W. Biederman wrote:
>> Thomas Gleixner writes:
>>> IMO, not bothering with an extra counter and rlimit plus the required
>>> atomic operations is just fine and having this for all tasks
>>> unconditionally looks like a clear win.
>>>
>
On Thu, Mar 11 2021 at 13:45, Thomas Gleixner wrote:
> On Thu, Mar 11 2021 at 00:56, Thomas Gleixner wrote:
>> Rant aside, there is no massive benefit of doing that caching in
>> general, but there is not much of a downside either and for particular
>> use cases it's useful even outside of PREEMPT
On Thu, Mar 11 2021 at 00:56, Thomas Gleixner wrote:
> Rant aside, there is no massive benefit of doing that caching in
> general, but there is not much of a downside either and for particular
> use cases it's useful even outside of PREEMPT_RT.
>
> IMO, having it there unconditionally is better tha
On Wed, Mar 10 2021 at 15:57, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>> IMO, not bothering with an extra counter and rlimit plus the required
>> atomic operations is just fine and having this for all tasks
>> unconditionally looks like a clear win.
>>
>> I'll post an updated version of
Thomas Gleixner writes:
> On Thu, Mar 04 2021 at 21:58, Thomas Gleixner wrote:
>> On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
>>> Thomas Gleixner writes:
We could of course do the caching unconditionally for all tasks.
>>>
>>> Is there any advantage to only doing this for re
On Thu, Mar 04 2021 at 21:58, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
>> Thomas Gleixner writes:
>>>
>>> We could of course do the caching unconditionally for all tasks.
>>
>> Is there any advantage to only doing this for realtime tasks?
>
> It was mostly to
On Tue, Mar 09 2021 at 13:01, Thomas Gleixner wrote:
> On Fri, Mar 05 2021 at 11:57, Oleg Nesterov wrote:
>> On 03/04, Thomas Gleixner wrote:
>>> On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
>>> >> +static bool sigqueue_add_cache(struct task_struct *t, struct sigqueue
>>> >> *q)
>>> >> +{
>>
On 03/04, Thomas Gleixner wrote:
>
> On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
> > On 03/03, Sebastian Andrzej Siewior wrote:
> >>
> >> +static struct sigqueue *sigqueue_from_cache(struct task_struct *t)
> >> +{
> >> + struct sigqueue *q = t->sigqueue_cache;
> >> +
> >> + if (q && cmpxch
On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
> On 03/03, Sebastian Andrzej Siewior wrote:
>> +static void __sigqueue_cache_or_free(struct sigqueue *q)
>> +{
>> +struct user_struct *up;
>> +
>> +if (q->flags & SIGQUEUE_PREALLOC)
>> +return;
>> +
>> +up = q->user;
>> +
On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
> On 03/03, Sebastian Andrzej Siewior wrote:
>>
>> +static struct sigqueue *sigqueue_from_cache(struct task_struct *t)
>> +{
>> +struct sigqueue *q = t->sigqueue_cache;
>> +
>> +if (q && cmpxchg(&t->sigqueue_cache, q, NULL) == q)
>> +
On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>>
>> We could of course do the caching unconditionally for all tasks.
>
> Is there any advantage to only doing this for realtime tasks?
It was mostly to avoid tons of cached entries hanging around all over
the place
Thomas Gleixner writes:
> On Thu, Mar 04 2021 at 09:11, Sebastian Andrzej Siewior wrote:
>> On 2021-03-03 16:09:05 [-0600], Eric W. Biederman wrote:
>>> Sebastian Andrzej Siewior writes:
>>>
>>> > From: Thomas Gleixner
>>> >
>>> > Allow realtime tasks to cache one sigqueue in task struct. This
Sebastian Andrzej Siewior writes:
> On 2021-03-03 16:09:05 [-0600], Eric W. Biederman wrote:
>> Sebastian Andrzej Siewior writes:
>>
>> > From: Thomas Gleixner
>> >
>> > Allow realtime tasks to cache one sigqueue in task struct. This avoids an
>> > allocation which can increase the latency or
On Thu, Mar 04 2021 at 09:11, Sebastian Andrzej Siewior wrote:
> On 2021-03-03 16:09:05 [-0600], Eric W. Biederman wrote:
>> Sebastian Andrzej Siewior writes:
>>
>> > From: Thomas Gleixner
>> >
>> > Allow realtime tasks to cache one sigqueue in task struct. This avoids an
>> > allocation which c
On 2021-03-03 16:09:05 [-0600], Eric W. Biederman wrote:
> Sebastian Andrzej Siewior writes:
>
> > From: Thomas Gleixner
> >
> > Allow realtime tasks to cache one sigqueue in task struct. This avoids an
> > allocation which can increase the latency or fail.
> > Ideally the sigqueue is cached aft
Sebastian Andrzej Siewior writes:
> From: Thomas Gleixner
>
> Allow realtime tasks to cache one sigqueue in task struct. This avoids an
> allocation which can increase the latency or fail.
> Ideally the sigqueue is cached after first successful delivery and will be
> available for next signal de
On 03/03, Sebastian Andrzej Siewior wrote:
>
> +static struct sigqueue *sigqueue_from_cache(struct task_struct *t)
> +{
> + struct sigqueue *q = t->sigqueue_cache;
> +
> + if (q && cmpxchg(&t->sigqueue_cache, q, NULL) == q)
> + return q;
> + return NULL;
> +}
> +
> +static b
From: Thomas Gleixner
Allow realtime tasks to cache one sigqueue in task struct. This avoids an
allocation which can increase the latency or fail.
Ideally the sigqueue is cached after first successful delivery and will be
available for next signal delivery. This works under the assumption that th
18 matches
Mail list logo
