Re: radeon fence object allocation and free frequently
Jerome Glisse wrote: 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 I've also had some concerns about fence object allocation / destruction in the past, but it seems, just like Jerome points out, that the slab / slub allocator does its job just fine, and I've never seen this end up high on benchmarks. /Thomas -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon fence object allocation and free frequently
dri-devel@lists.sourceforge.netHi 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. -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon fence object allocation and free frequently
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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon fence object allocation and free frequently
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. thanks. Donnie. 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
