Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1702402 > unrolled thread

Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys Davidlohr Bueso <dave@stgolabs.net> - 2017-08-02 22:10 +0200
    Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys Guillaume Knispel <guillaume.knispel@supersonicimagine.com> - 2017-08-03 19:20 +0200
      Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys Davidlohr Bueso <dave@stgolabs.net> - 2017-08-07 19:40 +0200

#1702402 — Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys

On Mon, 31 Jul 2017, Guillaume Knispel wrote:
> static int __init ipc_init(void)
> {
>-	sem_init();
>-	msg_init();
>+	int err_sem, err_msg;
>+
>+	err_sem = sem_init();
>+	WARN(err_sem, "ipc: sysV sem_init failed: %d\n", err_sem);
>+	err_msg = msg_init();
>+	WARN(err_msg, "ipc: sysV msg_init failed: %d\n", err_msg);
> 	shm_init();

This shows the ugliness of the underlying ipc init asymmetry. Specifically,
140d0b2108f (Do 'shm_init_ns()' in an early pure_initcall) was the final
nail in the coffin to fix an exit_shm() race.

While normally we could just initialize the ipc_ids fields statically and
be over with initcall dependencies, your patch will require inits be done
dynamically for the rhashtable_init(). Oh well.

Also, why do you do this?

> -pure_initcall(ipc_ns_init);
> +core_initcall(ipc_ns_init);

Thanks,
Davidlohr

[toc] | [next] | [standalone]

#1703296

On Wed, Aug 02, 2017 at 01:06:44PM -0700, Davidlohr Bueso wrote:
> On Mon, 31 Jul 2017, Guillaume Knispel wrote:
> >static int __init ipc_init(void)
> >{
> >-	sem_init();
> >-	msg_init();
> >+	int err_sem, err_msg;
> >+
> >+	err_sem = sem_init();
> >+	WARN(err_sem, "ipc: sysV sem_init failed: %d\n", err_sem);
> >+	err_msg = msg_init();
> >+	WARN(err_msg, "ipc: sysV msg_init failed: %d\n", err_msg);
> >	shm_init();
> 
> This shows the ugliness of the underlying ipc init asymmetry. Specifically,
> 140d0b2108f (Do 'shm_init_ns()' in an early pure_initcall) was the final
> nail in the coffin to fix an exit_shm() race.
> 
> While normally we could just initialize the ipc_ids fields statically and
> be over with initcall dependencies, your patch will require inits be done
> dynamically for the rhashtable_init(). Oh well.
> 
> Also, why do you do this?
> 
> >-pure_initcall(ipc_ns_init);
> >+core_initcall(ipc_ns_init);

In linux/init.h I saw that a pure_initcall is reserved to only
initialize variables and must have no dependency on anything else;
I interpreted that, + "pure" in the name, thinking we should not e.g.
allocate in a pure_initcall, however I see that net_ns_init() calls
kmem_cache_create() and others, so maybe we can keep ipc_ns_init() as
a pure_initcall?

Guillaume

[toc] | [prev] | [next] | [standalone]

#1705730

On Thu, 03 Aug 2017, Guillaume Knispel wrote:

>In linux/init.h I saw that a pure_initcall is reserved to only
>initialize variables and must have no dependency on anything else;
>I interpreted that, + "pure" in the name, thinking we should not e.g.
>allocate in a pure_initcall, however I see that net_ns_init() calls
>kmem_cache_create() and others, so maybe we can keep ipc_ns_init() as
>a pure_initcall?

Yeah, I don't see this as a limitation wrt link order. Among others,
filelocks also do this. Not to mention futexes with alloc_large_system_hash().
So lets just keep this as is.

Thanks,
Davidlohr

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web