Andrew Morton writes:
> On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano
> wrote:
>
>> Andrew Morton writes:
>>
>> > OK, but this simply moves the expense so it happens later on. Why is
>> > that better?
>>
>> the optimization is for new IPC namespaces that don't use mq_open. In
>> thi
On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano
wrote:
> Andrew Morton writes:
>
> > OK, but this simply moves the expense so it happens later on. Why is
> > that better?
>
> the optimization is for new IPC namespaces that don't use mq_open. In
> this case there won't be any kern_mount
Andrew Morton writes:
> OK, but this simply moves the expense so it happens later on. Why is
> that better?
the optimization is for new IPC namespaces that don't use mq_open. In
this case there won't be any kern_mount_data cost at all.
Regards,
Giuseppe
On Mon, 27 Nov 2017 13:55:50 +0100 Giuseppe Scrivano
wrote:
> kern_mount_data is a relatively expensive operation when creating a
> new IPC namespace, so delay the mount until its first usage when not
> creating the the global namespace.
>
> On my machine, the time for creating 1000 new IPC nam
This is akpm domain.
On Mon, 27 Nov 2017, Giuseppe Scrivano wrote:
kern_mount_data is a relatively expensive operation when creating a
new IPC namespace, so delay the mount until its first usage when not
creating the the global namespace.
On my machine, the time for creating 1000 new IPC names
kern_mount_data is a relatively expensive operation when creating a
new IPC namespace, so delay the mount until its first usage when not
creating the the global namespace.
On my machine, the time for creating 1000 new IPC namespaces dropped
from ~8s to ~2s.
Signed-off-by: Giuseppe Scrivano
---
6 matches
Mail list logo
