| 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
| ||
|
Message-ID: <877i4pdx4f.fsf@basil.nowhere.org> Date: Wed, 21 Jan 2009 06:52:16 +0100 From: Andi Kleen <andi@...stfloor.org> To: Mike Waychison <mikew@...gle.com> Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH v1 0/8] Deferred dput() and iput() -- reducing lock contention Mike Waychison <mikew@...gle.com> writes: > livelock on dcache_lock/inode_lock (specifically in atomic_dec_and_lock()) I'm not sure how something can livelock in atomic_dec_and_lock which doesn't take a spinlock itself? Are you saying you run into NUMA memory unfairness here? Or did I misparse you? > This patchset is an attempt to try and reduce the locking overheads associated > with final dput() and final iput(). This is done by batching dentries and > inodes into per-process queues and processing them in 'parallel' to consolidate > some of the locking. I was wondering what this does to the latencies when dput/iput is only done for very objects. Does it increase costs then significantly? As a high level comment it seems like a lot of work to work around global locks, like the inode_lock, where it might be better to just split the lock up? Mind you I don't have a clear proposal how to do that, but surely it's doable somehow. -Andi -- ak@...ux.intel.com -- Speaking for myself only. -- 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/
Powered by blists - more mailing lists