linux-kernel - Re: [RFC PATCH 0/7] Improve swiotlb performance by using physical addresses

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: <20121005200245.GQ16230@one.firstfloor.org>
Date:	Fri, 5 Oct 2012 22:02:45 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	Andi Kleen <andi@...stfloor.org>, konrad.wilk@...cle.com,
	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	rob@...dley.net, akpm@...ux-foundation.org, joerg.roedel@....com,
	bhelgaas@...gle.com, shuahkhan@...il.com,
	linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
	x86@...nel.org, torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH 0/7] Improve swiotlb performance by using physical addresses

> I was thinking the issue was all of the calls to relatively small
> functions occurring in quick succession.  The way most of this code is
> setup it seems like it is one small function call in turn calling
> another, and then another, and I would imagine the code fragmentation
> can have a significant negative impact.

Maybe. Can you just inline everything and see if it it's faster then?

This was out of line when the "text cost at all costs" drive was still
envogue, but luckily we're not doing  that anymore.

-Andiu

-- 
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/