netdev - Re: [RFC 2/2] shrink size of scatterlist on common i386/x86-64

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]

Message-Id: <20070706.122019.55506705.davem@davemloft.net>
Date:	Fri, 06 Jul 2007 12:20:19 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mitch.a.williams@...el.com
Cc:	shemminger@...ux-foundation.org, netdev@...r.kernel.org
Subject: Re: [RFC 2/2] shrink size of scatterlist on common i386/x86-64

From: "Williams, Mitch A" <mitch.a.williams@...el.com>
Date: Fri, 6 Jul 2007 10:14:56 -0700

> In my opinion, IOMMU table locking is the major issue with this type of
> architecture.  Since both Intel and AMD are touting IOMMUs for virtual-
> ization support, this is an issue that's going to need a lot of
> scrutiny.

For the allocation of IOMMU entries themselves you can play tricks
using atomic operations on 64-bit words of the allocator bitmap
to avoid locking that.

You can use per-cpu salts to determine where to start the search
and avoid hitting the same cachelines as other cpus working on
the same table.

But you'll need to lock in order to flush the IOMMU tlb I'm afraid.
The way to mitigate that is to only flush the IOMMU tlb once per
allocator generation.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html