public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Gargi Sharma <gs051095@gmail.com>
Cc: linux-kernel@vger.kernel.org, riel@surriel.com,
	julia.lawall@lip6.fr, akpm@linux-foundation.org,
	mingo@kernel.org, pasha.tatashin@oracle.com,
	ktkhai@virtuozzo.com, oleg@redhat.com
Subject: Re: [PATCH v2 0/2] Replace PID bitmap allocation with IDR API
Date: Wed, 27 Sep 2017 12:18:08 -0500	[thread overview]
Message-ID: <87ing4vz5b.fsf@xmission.com> (raw)
In-Reply-To: <cover.1506488388.git.gs051095@gmail.com> (Gargi Sharma's message of "Wed, 27 Sep 2017 01:06:01 -0400")

Gargi Sharma <gs051095@gmail.com> writes:

> This patch series replaces kernel bitmap implementation of PID allocation
> with IDR API. These patches are written to simplify the kernel by replacing custom code with calls to generic code.
>
> The following are the stats for pid and pid_namespace object files
> before and after the replacement. There is a noteworthy change between
> the IDR and bitmap implementation.
>
> Before
> text       data        bss        dec        hex    filename
>    8447       3894         64      12405       3075    kernel/pid.o
> After
> text       data        bss        dec        hex    filename
>    3301        304          0       3605        e15    kernel/pid.o
>
> Before
>  text       data        bss        dec        hex    filename
>    5692       1842        192       7726       1e2e    kernel/pid_namespace.o
> After
> text       data        bss        dec        hex    filename
>    2870        216         16       3102        c1e    kernel/pid_namespace.o
>
> There wasn't a considerable difference between the time required for
> allocation of PIDs to the processes.

How about the time to call readdir on /proc?

How many processes were you testing with?

Why just the bitmap?  Why not update the hash table as well.
An rbtree or an rhashtable might be better.

Hmm.  Oh look there is patch 2/2 and you do replace the hashtable with
the idr as well.  Now I am very interested in a comparison of data
structures.

How does the runtime memory footprint of your new pid hash
implementation compare to the old memory footprint?

There are a lot of options in this space and it does not sound like you
have looked at the options very thoroughly.

I am a little worried that in the quest to reuse code you may have made the
total amount of code executed larger and more susceptible to more cache line
misses.

>From what Oleg has pointed out and from your the holes in your
description I am generally leery of this patchset as the attention to
detail was appears lower than necessary for this to be more than a proof
of concept.

Eric


> ---
> Changes in v2:
>         - Removed redundant  IDR function that was introduced
>           in the previous patchset.
>         - Renamed PIDNS_HASH_ADDING
>         - Used idr_for_each_entry_continue()
>         - Used idr_find() to lookup pids
>
> Gargi Sharma (2):
>   pid: Replace pid bitmap implementation with IDR API
>   pid: Remove pidhash
>
>  arch/powerpc/platforms/cell/spufs/sched.c |   2 +-
>  fs/proc/loadavg.c                         |   2 +-
>  include/linux/init_task.h                 |   1 -
>  include/linux/pid.h                       |   2 -
>  include/linux/pid_namespace.h             |  18 +--
>  init/main.c                               |   3 +-
>  kernel/fork.c                             |   2 +-
>  kernel/pid.c                              | 239 +++++-------------------------
>  kernel/pid_namespace.c                    |  54 +++----
>  9 files changed, 68 insertions(+), 255 deletions(-)

  parent reply	other threads:[~2017-09-27 17:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27  5:06 [PATCH v2 0/2] Replace PID bitmap allocation with IDR API Gargi Sharma
2017-09-27  5:06 ` [PATCH v2 1/2] pid: Replace pid bitmap implementation " Gargi Sharma
2017-09-27 13:09   ` Rik van Riel
2017-09-27 14:06     ` Oleg Nesterov
2017-09-27 15:06       ` Gargi Sharma
2017-09-27 15:15         ` Oleg Nesterov
2017-09-27 15:05     ` Gargi Sharma
2017-09-27 15:05   ` Oleg Nesterov
2017-10-01  9:15   ` Christoph Hellwig
2017-10-01 10:35     ` Gargi Sharma
2017-10-02 13:14       ` Rik van Riel
2017-10-02 13:05     ` Rik van Riel
2017-09-27  5:06 ` [PATCH v2 2/2] pid: Remove pidhash Gargi Sharma
2017-09-27 15:45   ` Oleg Nesterov
2017-09-27 16:28     ` Oleg Nesterov
2017-09-30 15:41       ` Gargi Sharma
2017-10-02 15:03         ` Oleg Nesterov
2017-10-02 13:35     ` Rik van Riel
2017-10-02 13:45       ` Rik van Riel
2017-10-02 15:21       ` Oleg Nesterov
2017-10-02 15:22         ` Rik van Riel
2017-10-02 16:27           ` Gargi Sharma
2017-09-27 17:18 ` Eric W. Biederman [this message]
     [not found]   ` <CAOCi2DESqWV2YPcRTe6NYjx6m6N19ewXbAyfLfeBa23kJiEO9Q@mail.gmail.com>
2017-09-28 19:46     ` [PATCH v2 0/2] Replace PID bitmap allocation with IDR API Rik van Riel
2017-09-28 20:05       ` Gargi Sharma
2017-09-29  0:35         ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ing4vz5b.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=gs051095@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=pasha.tatashin@oracle.com \
    --cc=riel@surriel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox