Re: [RFC PATCH v3 1/2] tmpfs: manage the inode-number by IDR, signed int inum

[Jan Kara <jack@suse.cz>]

On Mon 02-06-14 01:18:56, J. R. Okajima wrote:
> To ensure the uniquness of the inode-number, manage it by IDR.
> Also it tries using the lowest unused inode-number, so the value will
> usually be smaller.
> Another side effect is the type of the inode-number in tmpfs. By using
> IDR, it is limited to signed int. But I don't think it a big
> problem. INT_MAX is big enough for the number of inodes in a single tmpfs.
  What I'm missing with this patch is some quantification of costs this
change has - i.e., it's surely going to cost us some performance. Can you
measure how much? I think measuring creation and deletion of lots of empty
files from 1, 2, 4, 8, .. NR_CPU processes (each process in a separate dir
to avoid contention on i_mutex) in tmpfs would make sense.

One correctness nit below as well.

> diff --git a/mm/shmem.c b/mm/shmem.c
> index 368f314..0023d8d 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -107,9 +107,13 @@ static unsigned long shmem_default_max_blocks(void)
>  	return totalram_pages / 2;
>  }
>  
> -static unsigned long shmem_default_max_inodes(void)
> +static int shmem_default_max_inodes(void)
>  {
> -	return min(totalram_pages - totalhigh_pages, totalram_pages / 2);
> +	int i;
> +
> +	i = min(totalram_pages - totalhigh_pages, totalram_pages / 2);
> +	i = min(i, INT_MAX);
  With i being 'int' this doesn't make much sense... I guess it should be
unsigned long.

> +	return i;
>  }
>  #endif

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR