On Mon, Aug 07, 2017 at 11:21:03AM -0700, Davidlohr Bueso wrote:
> On Mon, 31 Jul 2017, Guillaume Knispel wrote:
> > struct ipc_ids {
> > int in_use;
> > unsigned short seq;
> > + bool tables_initialized;
>
> So this is really ugly to have, but I understand why you added it. I
> wonder w
On Mon, 31 Jul 2017, Guillaume Knispel wrote:
struct ipc_ids {
int in_use;
unsigned short seq;
+ bool tables_initialized;
So this is really ugly to have, but I understand why you added it. I
wonder what folks would think if we just panic() in the rhashtable_init()
ENOMEM c
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 ne
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_ini
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_
On Tue, 01 Aug 2017, Guillaume Knispel wrote:
On Mon, Jul 31, 2017 at 08:45:58AM -0700, Davidlohr Bueso wrote:
On Mon, 31 Jul 2017, Guillaume Knispel wrote:
>ipc_findkey() scanned all objects to look for the wanted key. This is
>slow when using a high number of keys, for example on an i5 laptop
On Mon, Jul 31, 2017 at 08:45:58AM -0700, Davidlohr Bueso wrote:
> On Mon, 31 Jul 2017, Guillaume Knispel wrote:
> >ipc_findkey() scanned all objects to look for the wanted key. This is
> >slow when using a high number of keys, for example on an i5 laptop the
> >following loop took 17 s, with last
On Mon, 31 Jul 2017, Guillaume Knispel wrote:
ipc_findkey() scanned all objects to look for the wanted key. This is
slow when using a high number of keys, for example on an i5 laptop the
following loop took 17 s, with last semget calls taking ~1 ms each.
I would argue that this is not the comm
ipc_findkey() scanned all objects to look for the wanted key. This is
slow when using a high number of keys, for example on an i5 laptop the
following loop took 17 s, with last semget calls taking ~1 ms each.
for (int i = 0, k=0x424242; i < 31900; ++i)
semget(k++, 1, IPC_CREAT | 0600);
9 matches
Mail list logo