floating point support in the driver.

[Misbah khan]

Thank you Warner.

Actually the complete algorithm should take not more than 1 sec to execute
but its taking around 1.8 sec .The algorithm would rum between every few
secs. I am trying to fine tune the code ,i just want to know that will it a
good idea to alter the task priority and what could be the best way ?

-- Misbah <>< 

M. Warner Losh wrote:
> 
> In message: <18772952.post at talk.nabble.com>
>             Misbah khan <misbah_khan at engineer.com> writes:
> : I am not very clear Why floating point support in the Kernel should be
> : avoided ?
> 
> Because saving the FPU state is expensive.  The kernel multiplexes the
> FPU hardware among all the userland processes that use it.  For parts
> of the kernel to effectively use the FPU, it would have to save the
> state on traps into the kernel, and restore the state when returning
> to userland.  This is a big drag on performance of the system.  There
> are ways around this optimization where you save the fpu state
> explicitly, but the expense si still there.
> 
> : We want our DSP algorithm to run at the boot time and since kernel
> thread
> : having higher priority , i assume that it would be faster than user
> : application.
> 
> Bad assumption.  User threads can get boots in priority in certain
> cases.
> 
> If it really is just at boot time, before any other threads are
> started, you likely can get away with it.
> 
> : If i really have to speed up my application execution what mechanism
> will
> : you suggest me to try ?
> : 
> : After using Hardware VFP support also i am still laging the timing
> : requirement by 800 ms in my case 
> 
> This sounds like a classic case of putting 20 pounds in a 10 pound bag
> and complaining that the bag rips out.  You need a bigger bag.
> 
> If you are doing FPU intensive operations in userland, moving them to
> the kernel isn't going to help anything but maybe latency.  And if you
> are almost a full second short, your quest to move things into the
> kernel is almost certainly not going to help enough.  Moving things
> into the kernel only helps latency, and only when there's lots of
> context switches (since doing stuff in the kernel avoids the domain
> crossing that forces the save of the CPU state).
> 
> I don't know if the 800ms timing is relative to a task that must run
> once a second, or once an hour.  If the former, you're totally
> screwed and need to either be more clever about your algorithm
> (consider integer math, profiling the hot spots, etc), or you need
> more powerful silicon.  If you  are trying to shave 800ms off a task
> that runs for an hour, then you just might be able to do that with
> tiny code tweaks.
> 
> Sorry to be so harsh, but really, there's no such thing as a free lunch.
> 
> Warner
> 
> 
> 
> : ---- Misbah <><
> : 
> : 
> : Laurent Pinchart-4 wrote:
> : > 
> : > On Friday 01 August 2008, Misbah khan wrote:
> : >> 
> : >> Hi all,
> : >> 
> : >> I have a DSP algorithm which i am running in the application even
> after
> : >> enabling the VFP support it is taking a lot of time to get executed
> hence 
> : >> 
> : >> I want to transform the same into the driver insted of an user
> : >> application.
> : >> Can anybody suggest whether doing the same could be a better solution
> and
> : >> what could be the chalenges that i have to face by implimenting such
> : >> floating point support in the driver.
> : >> 
> : >> Is there a way in the application itself to make it execute faster.
> : > 
> : > Floating-point in the kernel should be avoided. FPU state save/restore
> : > operations are costly and are not performed by the kernel when
> switching
> : > from userspace to kernelspace context. You will have to protect
> : > floating-point sections with kernel_fpu_begin/kernel_fpu_end which, if
> I'm
> : > not mistaken, disables preemption. That's probably not something you
> want
> : > to do. Why would the same code run faster in kernelspace then
> userspace ?
> : > 
> : > -- 
> : > Laurent Pinchart
> : > CSE Semaphore Belgium
> : > 
> : > Chaussee de Bruxelles, 732A
> : > B-1410 Waterloo
> : > Belgium
> : > 
> : > T +32 (2) 387 42 59
> : > F +32 (2) 387 42 75
> : > 
> : >  
> : > _______________________________________________
> : > Linuxppc-embedded mailing list
> : > Linuxppc-embedded at ozlabs.org
> : > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> : > 
> : 
> : -- 
> : View this message in context:
> http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18772952.html
> : Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> : 
> : _______________________________________________
> : Linuxppc-embedded mailing list
> : Linuxppc-embedded at ozlabs.org
> : https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> : 
> : 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18805820.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.