linux-kernel - Re: [PATCH 15/17] fs: inode per-cpu last

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Sep 2010 22:07:59 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Chinner <david@...morbit.com>, dada1@...mosbay.com
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/17] fs: inode per-cpu last_ino allocator

On Wed, Sep 29, 2010 at 10:18:47PM +1000, Dave Chinner wrote:
> From: Eric Dumazet <dada1@...mosbay.com>
> 
> last_ino was converted to an atomic variable to allow the inode_lock
> to go away. However, contended atomics do not scale on large
> machines, and new_inode() triggers excessive contention in such
> situations.

And the good thing is most users of new_inode couldn't care less about
the fake i_ino assigned because they have a real inode number.  So
the first step is to move the i_ino assignment into a separate helper
and only use it in those filesystems that need it.  Second step is
to figure out why some filesystems need iunique() and some are fine
with the incrementing counter and then we should find a scalable way
to generate an inode number - preferably just one and not to, but if
that's not possible we need some documentation on why which one is
needed.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/