Ingo Molnar wrote:
* Nick Piggin <[email protected]> wrote:
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.
No, if you read what I'd been saying, I'm not dismissing the whole
subject based on the workload. I'm saying that there is no point to
include such a "fix" based on the numbers given by this workload (if
there is a more meaningful one, then sure). Especially not while
there are sources of equivalent latency.
It is really simple: I can find a code path in the kernel, and work
out how to exploit it by increasing resource loading until it goes
bang (another example, tasklist_lock).
This is not really a justification for trying to "fix" it.
Unless somewhere there was an agreement that 1.5ms interrupt latency
was a bug, full stop.
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.
That would be great. Actually I have some patches that move the actual
waking of the tasks out from underneath the lock too which gave some
scalability benefits (and I'd imagine far less interrupt-off time, so
let me know when you start work on rwsems).
But there are still places where interrupts can be held off for
indefinite periods. I don't see why the scheduler lock is suddenly
important - I could have told you years ago what would happen if you
trigger the load balancer with enough tasks.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
