linux-kernel - Re: swiotlb detection should be memory hotplug aware ?

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: <20100728190939D.fujita.tomonori@lab.ntt.co.jp>
Date:	Wed, 28 Jul 2010 19:10:19 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	ak@...ux.intel.com
Cc:	konrad.wilk@...cle.com, akataria@...are.com,
	fujita.tomonori@....ntt.co.jp, lenb@...nel.org, x86@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	petr@...are.com
Subject: Re: swiotlb detection should be memory hotplug aware ?

On Fri, 23 Jul 2010 17:23:33 +0200
Andi Kleen <ak@...ux.intel.com> wrote:

> 
> > I was thinking about this at some point. I think the first step is to
> > make SWIOTLB use the debugfs to actually print out how much of its
> > buffers are used - and see if the 64MB is a good fit.
> 
> swiotlb is near always wrongly sized. For most system it's far too much, 
> but for some
> not enough. I have some systemtap scripts around to instrument it.

True, it's impossible to preallocate the best iotlb size statically.

 
> Also it depends on the IO load, so if you size it reasonable you
> risk overflow on large IO (however these days this very rarely happens 
> because
> all "serious" IO devices don't need swiotlb anymore)

Yeah, nowadays it's pointless to try to get the good performance with
swiotlb.


> The other problem is that using only  two bits for the needed address 
> space is also extremly
> inefficient (4GB and 16MB on x86). Really want masks everywhere and 
> optimize for the
> actual requirements.

swiotlb doesn't allocate GFP_DMA memory. It handles only GFP_DMA32.

swiotlb doesn't work for drivers with some odd dma mask (non 32bit)
but we have been lived with it so I don't think that it's a big issue.


I think, supporting expanding swiotlb dynamically is enough. The
default swiotlb size, 64MB is too large for majority.

I have a half-baked patch for it. I'll send it later.
--
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/