Re: sched_yield() version 2.4.24

[ebiederm@xmission.com (Eric W. Biederman)]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

> On Tue, 30 Mar 2004, Richard B. Johnson wrote:
> 
> > On Tue, 30 Mar 2004, Denis Vlasenko wrote:
> >
> > > On Tuesday 30 March 2004 19:52, Ben Greear wrote:
> > > > Chris Friesen wrote:
> > > > > The cpu util accounting code in kernel/timer.c hasn't changed in 2.4
> > > > > since 2002.  Must be somewhere else.
> > > > >
> > > > > Anyone else have any ideas?
> > > >
> > > > As another sample point, I have fired up about 100 processes with
> > > > each process having 10+ threads.  On my dual-xeon, I see maybe 15
> > > > processes shown as 99% CPU in 'top'.  System load was near 25
> > > > when I was looking, but the machine was still quite responsive.
> > >
> > > There was a top bug with exactly this symptom. Fixed.
> > > I use procps-2.0.18.
> > >
> > Wonderful!  Now, where do I find the sources now that RedHat has
> > gone "commercial" and is keeping everything secret?
> >
> > I followed the http://sources.redhat.com/procps/  instructions
> > __exactly__ and get this:
> >
> > Script started on Tue Mar 30 15:27:02 2004
> > quark:/home/johnson/foo[1] cvs -d :pserver:anoncvs@sources.redhat.com:/procps
> login anoncvs
> 
> > Logging in to :pserver:anoncvs@sources.redhat.com:2401/procps
> > CVS password:
> > /procps: no such repository
> > quark:/home/johnson/foo[2] exit
> > Script done on Tue Mar 30 15:28:32 2004
> >
> 
> The RedHat server was apparently broken yesterday. There were many
> persons who tried to get the source. Eventually Burton Windle
> sent me a copy of the source, that he had previously acquired,
> after he tried to access it also.
> 
> I compiled the source and the problem persists. Any task that
> executes sched_yield() will get "charged" for the time that it
> has given away. This is not correct. Maybe it is not correctable,
> but it is still not correct. In addition to it being "unfair",
> it messes up the totals because tasks that are using the CPU time
> given up, also get charged.

Could it be that there are no other process with equal or greater
priority so that the process calling sched_yield gets called again?

Eric