Hi Jerome,
    Actually, I haven't done any benchmark yet.
The memory management itself is complicated and powerful, and the fence
object "allocate/free" is trivial to some extent in contrast with the memory
management. So maintain a pool in the driver is useless, meanwhile the
kernel slab act the same role in terms of pool. Got it.

2009/11/19 Jerome Glisse <gli...@freedesktop.org>

>  On Thu, 2009-11-19 at 16:29 +0800, Donnie Fang wrote:
> > Hi all,
> >     after reviewed the radeon fence scheme, there are lots of chances
> > that it needs create a new fence object, and also there are lots of
> > chances need to destroy these fence objects.
> >      In my opinion, is it possible to maintain a list for recording
> > some freed fence object for later usage and hence save performance. Am
> > i right?
> > Donnie.
> >
> Idea is that kernel allocator already do that for us. I would like to
> avoid having many pools in the driver, i don't think it's well behaving
> to do so. And fence are small enough to take advantage of any slab/slub
> allocator kernel has.
> However if you have benchmark that shows that fence allocation is
> slowing down, by huge margin, application than we might consider doing
> so. But i don't think fence are biggest bottleneck, i am pretty sure
> memory management is.
> Cheers,
> Jerome
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Dri-devel mailing list

Reply via email to