Hi Viraj, > I took these changes and built new bridgedriver.ko. > I could see 50% reduction in time taken to queue a buffer of size of > 3MB. (old time: 28 ms, new time: 13 ms). -------- Nice to hear the optimization worked for you. > But actually the L2 cache is only 256Kb. So a small part of the buffer > might be in cache (< 256Kb). > This will add unnecessary overhead for huge (my buffer size is 3MB) > buffers. > Is there any way so that I can flush full cache to avoid overhead? -------- I did benchmark the flush part and the number I got is very close to what you observed. We are looking into the issue of reducing the flush time. I will inform once I find any improvements to this. As far as your question regarding flushing the entire cache, I am not sure if this is the best approach as this will have an impact on the performance of other applications running in the system. Thank you, Best regards, Hari > -----Original Message----- > From: Viraj Karandikar [mailto:viraj.karandikar@xxxxxxxxxx] > Sent: Tuesday, June 10, 2008 10:51 AM > To: Kanigeri, Hari; Gupta, Ramesh; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge > > Thanks Hari, > I took these changes and built new bridgedriver.ko. > I could see 50% reduction in time taken to queue a buffer of size of > 3MB. (old time: 28 ms, new time: 13 ms). > > If I reserve and map a buffer only once and use the mapped address for > future (avoiding map/unmap every time) I get better numbers (9 ms). > So only thing which I am doing is flushing the buffer for consistency > since this buffer is input to codec on DSP. > > But 9ms only for flushing seems very high. > I am not 100% sure, but it seems like the kernel flush code is scanning > through all the virtual addresses of the buffer and flush if any of > those are cached. > But actually the L2 cache is only 256Kb. So a small part of the buffer > might be in cache (< 256Kb). > This will add unnecessary overhead for huge (my buffer size is 3MB) > buffers. > Is there any way so that I can flush full cache to avoid overhead? > > > Regards, > Viraj > > > > > > -----Original Message----- > From: Kanigeri, Hari [mailto:h-kanigeri2@xxxxxx] > Sent: Monday, June 09, 2008 10:51 PM > To: Viraj Karandikar; Gupta, Ramesh; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge > > Hi Viraj, > > You can use the attached file to get the DMM optimimzation that > Ramesh is referring to. > > The location of this file is mpu_driver\src\wmd\omap\3430 > > > Thank you, > Best regards, > Hari > > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx > > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Viraj > > Karandikar > > Sent: Monday, June 09, 2008 10:18 AM > > To: Gupta, Ramesh; linux-omap@xxxxxxxxxxxxxxx > > Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge > > > > Thanks Ramesh. > > I was reserving and mapping buffers "every time". This was not > > required. > > I modified the code to reserve and map a buffer only once and use the > > mapped address for future. > > This modification reduced the overhead. > > > > I have one more doubt. > > Does DSP use virtual-to-physical mapping for all the addresses it > > accesses (including DSP's local buffers)? > > Or it uses this mapping only to access shared buffers? > > Wont it be a big overhead if DSP accesses all the memories through > > virtual-to-physical mapping? > > > > Regards, > > Viraj > > > > > > > > -----Original Message----- > > From: Ramesh Gupta G [mailto:x0023949@xxxxxx] > > Sent: Monday, June 09, 2008 11:03 AM > > To: Viraj Karandikar; linux-omap-open-source@xxxxxxxxxxxxxx > > Subject: Re: Sharing buffers between ARM-DSP on OMAP3430 over Bridge > > > > Hi Vijay, > > > > ----- Original Message ----- > > From: "Viraj Karandikar" <viraj.karandikar@xxxxxxxxxx> > > To: <linux-omap-open-source@xxxxxxxxxxxxxx> > > Sent: Saturday, June 07, 2008 3:45 PM > > Subject: Sharing buffers between ARM-DSP on OMAP3430 over Bridge > > > > > > >Hi all, > > > > >I am working on omap3430 using bridge. I am using Dynamically Mapped > > >Memory (DMM) method for sharing buffers. > > > > >For sending buffers to DSP I am doing calls to > > >DSPProcessor_ReserveMemory() and DSPProcessor_Map(). For these calls > > are > > >taking around 18ms (for 3-4MB buffers) which is not > > acceptable for the > > >application. I am not able to understand why it is taking so > > much time? > > > > Which version of bridge you are using? > > We have optimized the code for DSPProcessor_Map(), You can see > > significant change in the numbers with the latest code. > > > > > > >My understanding of DMM method is -> > > > > > > >- Use malloc() to allocate a buffer on ARM. > > > > >- Reserve required chunk of memory from DMM pool (using > > >DSPProcessor_ReserveMemory() ) > > > > >- Translate this memory to ARM virtual address space in > > >DSPProcessor_Map() function. > > > > Actually DSPProcessor_Map() maps ARM physical addresses to DSP Virtual > > addresses. > > > > >- Send the reserved memory address to DSP. > > > > > > > > >Is this correct? I am confused about how exactly this happens. > > > > You are correct except above point about DSPProcessor_Map(). > > > > >Also Ihave a doubt if the reserved memory address is from > > DSP physical > > address > > >space? Or is it from ARM virtual address space for DSP > > physical address > > >space? > > > > Reserved Memory is from DSP Virtual Address. > > > > >Is DMM method does copy from malloc'ed address to reserved > > >address in any way? > > > > Do you mean copying the contents? No copying is involved. Only mapping > > of > > addresses is performed. > > > > > > >It will be helpful if anybody put some light on this. > > > > Please let me know if you see any issues. > > > > > > > > >Regards, > > > > >Viraj > > > > > > Thanks & Regards > > Ramesh Gupta G > > > > ********************************************************************** > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please notify > > helpdesk@xxxxxxxxxxx > > ********************************************************************** > > > > _______________________________________________ > > Linux-omap-open-source mailing list > > Linux-omap-open-source@xxxxxxxxxxxxxx > > http://linux.omap.com/mailman/listinfo/linux-omap-open-source > > > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-omap" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
