* Nick Piggin <[email protected]> wrote:
> Ingo Molnar wrote:
> >* Nick Piggin <[email protected]> wrote:
> >
> >
> >>What I am talking about is when you want a task to have the highest
> >>possible scheduling priority and you'd like to guarantee that it is
> >>not interrupted for more than Xus, including scheduling latency.
> >
> >
> >this is not a big issue in practice, because it's very hard to saturate
> >current x86 systems running the -rt kernel with pure IRQ load. The APIC
> >messages all have a natural latency, which serves as a throttler.
> >
>
> Either way, you don't measure it. Doesn't matter. As I said, off
> topic.
(sure we are measuring such effects too - our current worst-case latency
paths are related to two-irqs-after-each-other scenarios.)
> >>
> >>Then it is a fine hack for the RT kernel (or at least an improved,
> >>batched version of the patch). No arguments from me.
> >
> >
> >no, it is also fine for the mainline scheduler, as long as the patch is
> >clean and does the obviously right thing [which the current patch doesnt
> >offer]. A 1+ msec latency with irqs off is nothing to sniff at. Trying
>
> If it were generated by some real workload that cares, then I would care.
well, you might not care, but i do. It's up to you what you care about,
but right now the scheduler policy is that we do care about latencies.
Yes, it's obviously all subject to common sense, and if something
triggers in a rare and extreme workload then any change related to it
has a _much_ higher barrier of acceptance than a common codepath. But
your blanket dismissal of this whole subject based on the rarity of the
workload is just plain wrong.
> >to argue that 'you can get the same by using rwsems so why should we
> >bother' is pretty lame: rwsems are rare and arguably broken in
> >behavior, and i'd not say the same about the scheduler (just yet :-).
>
> I don't think it is lame at all. They're fairly important in use in
> mmap_sem that I know of. And I have seen workloads where the up_write
> path gets really expensive (arguably more relevant ones than
> hackbench).
they are broken e.g. in that they are mass-waking all the readers with
interrupts disabled. At a minimum rwsems should be declared irq-unsafe
(like mutexes), as all the substantial uses are in process-context
codepaths anyway. I'll revisit rwsems once the current mutex work is
done.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]
