Nathan Lynch wrote:
Nick Piggin wrote:
Note that I happen to also think the idea (brsems) have merit, and
that cpucontrol may be one of the places where a sane implementation
would actually be useful... but at least when you're introducing
this kind of complexity anywhere, you *really* need to be able to
back it up with numbers.
The only performance-related complaint with cpu hotplug of which I'm
aware -- that taking a cpu down on a large system can be painfully
slow -- resides in the "write side" of the code, which is not the case
that the brsem implementation optimizes. I think this patch would
make that case even worse. So I don't think it's appropriate to use a
brsem for cpu hotplug, especially without trying rwsem first.
I'm not sure that a brsem would make a noticable difference.
It isn't that cpu hotplug semaphore is a performance problem
now, but that it isn't being used in as many cases as it could
be due to its unscalable nature. For example, a while back I
wanted to use it in the fork() path in the scheduler but
couldn't.
Anyway, as I said, you need to be able to back it up with
numbers ;)
Nick
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |