Re: pci_pool reap?

[Daniel Stodden <stodden@in.tum.de>]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

hi.
 
On Tue, 2002-02-12 at 03:44, David S. Miller wrote:
>    From: Gérard Roudier <groudier@free.fr>
>    Date: Sun, 10 Feb 2002 21:20:05 +0100 (CET)
> 
>    On Mon, 11 Feb 2002, Alan Cox wrote:
>    
>    > This function may not be called in interrupt context.
>    
>    Such limitation looks poor implementation to me.
> 
> I agree with you Gerard, and probably nobody truly even requires
> this limitation.  I do plan to remove it after I've done a thorough
> investigation of the platform implementations.

ok, i've looked through most of 2.5.4 now.
results look like this:

			pci_alloc_consistent()	pci_free_consistent()
i386:
		[1]	ok			ok

ppc:
		[1]	ok			ok

mips:
		[1]	ok			ok

sh:
		[1]	ok			ok
  stm:		[1]	ok			ok
  dc:		[3]	ok			ok

mips64:
  ip32:		[1]	ok			ok
  ip27:		[1]	ok			ok

sparc:
		[1]	GFP_KERNEL		ok
sparc64:
		[2]	ok			ok

arm:		[4]	BUG()/GFP_KERNEL	BUG()

alpha:
		[2]	ok			ok

ia64:		[5]	ok?			ok?

		
[1]
gfp() + __pa() (or similar)

[2]
gfp() + IOMMU

[3]
dummy, offsets only

[4]     
ARM does GFP_KERNEL, and then __ioremaps the underlying pages.
ugh. is that the only way to get the area coherent?
furthermore i don't see why this could not be interrupt safe.

[5]
i don't understand ia64. but it looks somewhat atomic :)

well, assuming i didn't oversee anything, there are indeed few reasons
left why the whole _consistent() machinery shouldn't be callable from
interrupts. 

back to my original question: what were the last trees with shrinking
pools? would the original version still work or any redesigns needed?


regards,
dns

-- 
___________________________________________________________________________
 mailto:stodden@in.tum.de


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]