Re: [PATCH v7 3/4] ipc: Allow boot time extension of IPCMNI from 32k to 2M

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 07, 2018 at 04:59:11PM -0400, Waiman Long wrote:
> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
> index 49f9bf4..d62335f 100644
> --- a/ipc/ipc_sysctl.c
> +++ b/ipc/ipc_sysctl.c
> @@ -120,7 +120,8 @@ static int proc_ipc_sem_dointvec(struct ctl_table *table, int write,
>  static int zero;
>  static int one = 1;
>  static int int_max = INT_MAX;
> -static int ipc_mni = IPCMNI;
> +int ipc_mni __read_mostly = IPCMNI;
> +int ipc_mni_shift __read_mostly = IPCMNI_SHIFT;
>  
>  static struct ctl_table ipc_kern_table[] = {
>  	{

Is use of ipc_mni and ipc_mni_shift a hot path? As per Christoph Lameter,
its use should be reserved for data that is actually used frequently in hot
paths, and typically this was done after performance traces reveal contention
because a neighboring variable was frequently written to [0]. These would also
be tightly packed, to reduce the number of cachelines needed to execute a
critical path, so we should be selective about what variables use it.

Your commit log does not describe why you'd use __read_mostly here. It would
be useful if it did.

[0] https://lkml.kernel.org/r/alpine.DEB.2.11.1504301343190.28879@xxxxxxxxxx

  Luis



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux