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@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
