Messages in this thread | | | Date | Fri, 26 Oct 2012 11:12:33 -0700 | From | Juri Lelli <> | Subject | Re: [PATCH 01/16] math128: Introduce various 128bit primitives |
| |
Hi, first of all thanks to everybody for all this comments!
On 10/26/2012 05:56 AM, Peter Zijlstra wrote: > On Fri, 2012-10-26 at 12:44 +0200, Peter Zijlstra wrote: >>> We can still have the user space interface handing in the information >>> in nsec resolution, but it's reasonable to scale it down to something >>> useful. Just shift the incoming information right by 10, so you're in >>> the 1us resolution for all the internal math and all your limitation >>> problems are gone. A shift by ten for converting back and forth to >>> nsecs is not a real performance issue. >> >> I'm fine with that.. all I wanted was to not have the undefined overflow >> we initially had. > > Note that we still need the constraint checking with this, although with > both values shifted right 10 bits the range is now much bigger and > shouldn't be a practical limit anymore. >
I'll try to recap what seems to me you agreed and what will be the changes for the next iteration.
- remove first two patches (u128 math) [and keep them in a safe place just in case following constraints will annoy future generation users :P]
- scale down (right by 10) incoming parameters as to do internal math with ~1us resolution (and scale up outgoing params)
- insert new constraints on -dl entities parameters:
o since we have - dl_period >= dl_deadline >= dl_runtime - the only constraint we have to add for the overflow problem should be dl_period * dl_runtime < U64_MAX
o to rule out problems with <= 1000ns parameters just force the user to pass > 1000ns parameters (in the end its our real resolution)
- WARN_ONCE() in proper places
- properly document all this (comments and Documentation)
What you think?
Thanks a lot and Regards,
- Juri
| |