On 03/12, Eric W. Biederman wrote:
>
> I am going to kibitz just a little bit more.
>
> When I looked at this a second time it became apparent that using
> pid_task twice should actually be faster as it removes a dependent load
> caused by thread_group_leader, and replaces it by accessing two
Here are the micro-benchmark results. I ended up reworking it to use
google's benchmark tool [1]. For each N I timed how long it took to fork
a new child and then immediately wait on it, while already having N
other children. (Initially I tried to vfork, but that didn't play nicely
with the
Jim Newsome writes:
> On 3/12/21 14:29, Eric W. Biederman wrote:
>> When I looked at this a second time it became apparent that using
>> pid_task twice should actually be faster as it removes a dependent load
>> caused by thread_group_leader, and replaces it by accessing two adjacent
>> pointers
On 3/12/21 14:29, Eric W. Biederman wrote:
> When I looked at this a second time it became apparent that using
> pid_task twice should actually be faster as it removes a dependent load
> caused by thread_group_leader, and replaces it by accessing two adjacent
> pointers in the same cache line.
>
Jim Newsome writes:
> do_wait is an internal function used to implement waitpid, waitid,
> wait4, etc. To handle the general case, it does an O(n) linear scan of
> the thread group's children and tracees.
>
> This patch adds a special-case when waiting on a pid to skip these scans
> and instead
(Re-sent without html part, which the list rejected)
On 3/12/21 12:47, Andrew Morton wrote:
> IOW, please spend a bit of time selling the patch! What is the case
> for including it in Linux? What benefit does it provide our users?
Ah yes - I'd included some context when I first reached out to
On Fri, 12 Mar 2021 12:39:12 -0600 Jim Newsome wrote:
> On 3/12/21 12:22, Andrew Morton wrote:
> >
> > Could we please see some performance testing results to permit us to
> > evaluate the value of this change?
>
> Sure. I've been doing some ad-hoc measurements with the code below. It
> forks
On 3/12/21 12:22, Andrew Morton wrote:
>
> Could we please see some performance testing results to permit us to
> evaluate the value of this change?
Sure. I've been doing some ad-hoc measurements with the code below. It
forks 8k children and then waits for them in reverse order (forcing a
full
On Fri, 12 Mar 2021 11:38:55 -0600 Jim Newsome wrote:
> do_wait is an internal function used to implement waitpid, waitid,
> wait4, etc. To handle the general case, it does an O(n) linear scan of
> the thread group's children and tracees.
>
> This patch adds a special-case when waiting on a pid
do_wait is an internal function used to implement waitpid, waitid,
wait4, etc. To handle the general case, it does an O(n) linear scan of
the thread group's children and tracees.
This patch adds a special-case when waiting on a pid to skip these scans
and instead do an O(1) lookup. This improves
10 matches
Mail list logo
