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] [day] [month] [year] [list]

Message-Id: <20100728232026V.fujita.tomonori@lab.ntt.co.jp>
Date:	Wed, 28 Jul 2010 23:20:59 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	andi@...stfloor.org
Cc:	fujita.tomonori@....ntt.co.jp, ak@...ux.intel.com,
	konrad.wilk@...cle.com, akataria@...are.com, 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 Wed, 28 Jul 2010 13:09:57 +0200
Andi Kleen <andi@...stfloor.org> wrote:

> FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> writes:
> >
> >> 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.
> 
> I was lumping GFP_DMA and swiotlb together here. The
> pci_alloc_consistent() function uses both interchangedly.
> They really effectively are the same thing these days
> and just separated by historical accident.

Sorry, I meant to ZONE_DMA.

You are talking about your dma mask allocation patchset, right?

I meant that swiotlb doesn't need to handle ZONE_DMA. It handles only
devices that can handle ZONE_DMA32.


> > I have a half-baked patch for it. I'll send it later.
> 
> The problem are still the *_map users which usually cannot sleep,
> and then it's difficult to grow.

Why we can't use GFP_NOWAIT?

My approach is starting with small (like 4MB) and increasing io_tbl by
chunk such as 4MB.
--
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/