On Thu, 2 Jun 2005 04:41, Steve Rotolo wrote: > I guess the bottom-line is: given N logical cpus, 1/N of all > SCHED_NORMAL tasks may get stuck on a sibling cpu with no chance to > run. All it takes is one spinning SCHED_FIFO task. Sounds like a bug. You're right, and excuse me for missing it. We have to let SCHED_NORMAL tasks run for some period with rt tasks. There shouldn't be any combination of mutually exclusive tasks for siblings. I'll work on something. Cheers, Con
Attachment:
pgp0zGODgvqIK.pgp
Description: PGP signature
- Follow-Ups:
- Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- From: Joe Korty <[email protected]>
- Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- From: Steve Rotolo <[email protected]>
- Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- From: Con Kolivas <[email protected]>
- Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- References:
- SD_SHARE_CPUPOWER breaks scheduler fairness
- From: Steve Rotolo <[email protected]>
- Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- From: Con Kolivas <[email protected]>
- Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- From: Steve Rotolo <[email protected]>
- SD_SHARE_CPUPOWER breaks scheduler fairness
- Prev by Date: Re: 2.6.12-rc5: sleeping function called from invalid context (qla2xxx/scsi_transport_fc?)
- Next by Date: Re: RT patch acceptance
- Previous by thread: Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- Next by thread: Re: SD_SHARE_CPUPOWER breaks scheduler fairness
- Index(es):