Re: SD_SHARE_CPUPOWER breaks scheduler fairness

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]>

• 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]>

• 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):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]