Re: [patch drm] via unichrome improvements

[Thomas <uni...@sh...>]

> Hello Thomas,
>

>> Patch 3: I agree that there is checking needed for the returned index
>> values, but can't this be solved using range checking on the kernel
>> pointers,
>> or perhaps store the pointers in a hash table, the content of which is
>> verified before a memblock is freed?
>> It seems very inefficient to loop through the block map (up to 5000
>> blocks) on each allocation.
>
> My solution is not less efficient than the old situation. The old mm co=
de
> can do fast mem_alloc() but will loop through all allocated blocks on
> mem_free() (twice). My current solution will loop on mem_alloc() but ha=
s
> a faster mem_free().

Ah, OK. I didn't check the old code close enough.
>
> If you are concerned, I can use hashing to speed up mem_alloc(). I did
> this originally but then thought it not worthwhile. A possible approach
> is attached as 03a_via_mm_cleanup. This will of course turn slow again
> when the number of allocated blocks passes a certain treshold.
>

This seems better. I'll perhaps modify it slightly to have 4096 or 8192
hash entries in which case one can use an '&' operation instead of a '%'.
Also on linux one can possibly use the <linux/hash.h> hash function.
The reason I'm concerned about performance is because it would be good to
also have EXA (the new Xorg acceleration architecture) use the drm memory
manager when DRI is enabled. EXA would alloc / free for each entry in the
pixmap cache.

On the other hand I will hold commiting this patch for a little while,
since Eric Anholt has a complete reimplementation of the memory manager
both for SiS and for via somewhere in the pipeline. The map you propose
might have to be implemented on top of that as well, however.

>
> The old solution passes a kernel pointer to userspace as a unsigned lon=
g.
> This should work in i386 as well as pure x86_64, but not in x86_64 with
> 32-bit compatibility. To be honest, I did not even test it; it simply
> cannot work.

Agreed.

I'll also commit the ioctl32 stuff when the memory manager is fixed up.
The other patches have already been commited to both "linux-core" and
"linux" (2.4).

Thanks.

Thomas


>
> Bye,
>   Joris.
>