sched_yield() is iffe'd on systems that don't have it calls ast::tvsleep() => nanosleep()
On Wed, 21 Aug 2013 17:21:29 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= wrote: > Does asoyield() call sched_yield()? The reason for sched_yield() is > that the kernel scheduler is aware that the process is spinning, at > the first use of scheld_yield(). For most kernels this sets a flag > internally, so priority adjustments for fast, repeated sched_yield() > usage happens immediately - which avoids that the kernel has to use > statistics for cpu hogging processes instead - which are wrong in this > case. Use of nanosleep() or similar apis MUST be avoided, at all cost, > because the kernel will see this as sign, that the process is doing > important stuff and has to be put on top of the scheduler queue each > time the time out expires. This makes spin locks implemented via > nanosleep() so bad, they just hog the cpu, at all costs, to the > *severe* (unfair!!) disadvantage of all other processes. > Olga > On Wed, Aug 21, 2013 at 5:12 PM, Glenn Fowler <[email protected]> wrote: > > > > in ast call asoyield() for sched_yield() > > > > On Wed, 21 Aug 2013 16:58:40 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= > > wrote: > >> David, about 2., the code should *NOT* use sleep() or nanosleep() to > >> wait after EAGAIN or you risk *DRAMATIC* priority inversion problems. > >> I have experimented with this and EAGAIN can happen 2000, 200, 20, or > >> just 2 times, or 0 times. > >> The best solution we found is just to call sched_yield() and let the > >> process spin. This will not affect system performance as the code > >> walked in userland is very very small, and sched_yield() will > >> guarantee that the kernel will only give CPU time if the scheduler > >> queue cycles. At the same time, if sched_yield() is used (not > >> nanosleep()!!!!!), the scheduler will give less and less priority to > >> the spinning process. I tested this on Solaris, Linux, Illumos, > >> FreeBSD and OSX. > > > >> Olga > > > >> On Wed, Aug 21, 2013 at 4:09 PM, David Korn <[email protected]> wrote: > >> > cc: [email protected] > >> > Subject: Re: Re: [ast-developers] [patch] kill(1) |sigqueue()| > >> > fixes+|EAGAIN| handling etc. ... / was: Re: |sigqueue()| fixes+|EAGAIN| > >> > handling etc. ... > >> > -------- > >> > > >> >> Attached (as "astksh20130814_sigqueuerepeat002.diff.txt") is a patch > >> >> which fixes (some of) the issues listed above... > >> > > >> > > >> > I read over Rolands patch and while it contains useful ideas, I have > >> > some problems with it. > >> > > >> > Let me go over them piece by piece. > >> > > >> > 1. Add -Q to pass addresses. > >> > Currently the shell has no way of utilizing an address so there > >> > is no present need. Currently, the value field models the > >> > C standard and treats value as a union. However, it could treat > >> > the field as an integer choosing the large of void* and int as > >> > the size and pass the value that way. I would add a typedef > >> > for this type. It would be an integral type rather than a union. > >> > A user could do kill -q $((0x4000abc)) or just kill -q 0x4000abc > >> > to > >> > send a pointer since optget will convert to an integer. > >> > Programs could format the value as an address or as an int. > >> > I think that this needs more discussion before adding -Q. > >> > Commands already have too many options so I am reluctant to > >> > add an option unless necessary. > >> > > >> > 2. Add -R to handle EAGAIN > >> > I don't think that this is needed. EAGAIN should be handled > >> > as it is with fork with an exponential back-off algorithm that > >> > times out after around 30 seconds. EINTR will cause a retry > >> > unless trapnote has pending trap or signal to process in which > >> > case kill will fail. > >> > > >> > 3. Add -C to not send SIGCONT when sending a signal. I don't > >> > see why you would want to send a signal to a stopped process > >> > and not have it react. I believe that C-shell (the originator > >> > of job control) always sent SIGCONT. If there is a need for > >> > this, I could be convinced. > >> > > >> > Let me know what you think. > >> > > >> > David Korn > >> > [email protected] > >> > _______________________________________________ > >> > ast-developers mailing list > >> > [email protected] > >> > http://lists.research.att.com/mailman/listinfo/ast-developers > > > >> -- > >> , _ _ , > >> { \/`o;====- Olga Kryzhanovska -====;o`\/ } > >> .----'-/`-/ [email protected] \-`\-'----. > >> `'-..-| / http://twitter.com/fleyta \ |-..-'` > >> /\/\ Solaris/BSD//C/C++ programmer /\/\ > >> `--` `--` > > > -- > , _ _ , > { \/`o;====- Olga Kryzhanovska -====;o`\/ } > .----'-/`-/ [email protected] \-`\-'----. > `'-..-| / http://twitter.com/fleyta \ |-..-'` > /\/\ Solaris/BSD//C/C++ programmer /\/\ > `--` `--` _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
