AIM7 40% regression with 2.6.26-rc1
in [Kernel]
|
Prev: on CONFIG_MM_OWNER=y, kernel panic is possible.
Next: on CONFIG_MM_OWNER=y, kernel panic is possible.
From: Linus Torvalds on 7 May 2008 10:40 On Wed, 7 May 2008, Andi Kleen wrote: > > I am aware of that commit, thank you, but the comment was refering to that it > came with about zero justification why it was done. For the left over BKL > regions which are relatively short surely a spinlock would be better than a > semaphore? So PREEMPT_BKL should have been removed, not !PREEMPT_BKL. I do agree. I think turning the BKL into a semaphore was fine per se, but that was when semaphores were fast. Considering the apparent AIM regressions, we really either need to revert the semaphore consolidation, or we need to fix the kernel lock. And by "fixing", I don't mean removing it - it will happen, but it almost certainly won't happen for 2.6.26. The easiest approach would seem to just turn the BKL into a mutex instead, which should hopefully be about as optimized as the old semaphores. But my preferred option would indeed be just turning it back into a spinlock - and screw latency and BKL preemption - and having the RT people who care deeply just work on removing the BKL in the long run. Is BKL preemption worth it? Sounds very dubious. Sounds even more dubious when we now apparently have even more reason to aim for removing the BKL rather than trying to mess around with it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 7 May 2008 10:50 > But my preferred option would indeed be just turning it back into a > spinlock - and screw latency and BKL preemption - and having the RT people > who care deeply just work on removing the BKL in the long run. It isn't as if the RT build can't use a different lock type to the default build. > Is BKL preemption worth it? Sounds very dubious. Sounds even more dubious > when we now apparently have even more reason to aim for removing the BKL > rather than trying to mess around with it. We have some horrible long lasting BKL users left unfortunately. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 7 May 2008 11:00 > I think turning the BKL into a semaphore was fine per se, Are there really that many long lived BKL holders? I have some doubts. Semaphore makes only sense when the critical region is at least many thousands of cycles to amortize the scheduling overhead. Ok perhaps this needs some numbers to decide. but that was > when semaphores were fast. The semaphores should be still nearly as fast in theory, especially for the contended case. > Considering the apparent AIM regressions, we really either need to revert > the semaphore consolidation, Or figure out what made the semaphore consolidation slower? As Ingo pointed out earlier 40% is unlikely to be a fast path problem, but some algorithmic problem. Surely that is fixable (even for .26)? Perhaps we were lucky it showed so easily, not in something tricky. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 May 2008 11:10 On Wed, 7 May 2008, Alan Cox wrote: > > > But my preferred option would indeed be just turning it back into a > > spinlock - and screw latency and BKL preemption - and having the RT people > > who care deeply just work on removing the BKL in the long run. > > It isn't as if the RT build can't use a different lock type to the > default build. Well, considering just *how* bad the new BKL apparently is, I think that's a separate issue. The semaphore implementation is simply not worth it. At a minimum, it should be a mutex. > > Is BKL preemption worth it? Sounds very dubious. Sounds even more dubious > > when we now apparently have even more reason to aim for removing the BKL > > rather than trying to mess around with it. > > We have some horrible long lasting BKL users left unfortunately. Quite frankly, maybe we _need_ to have a bad BKL for those to ever get fixed. As it was, people worked on trying to make the BKL behave better, and it was a failure. Rather than spend the effort on trying to make it work better (at a horrible cost), why not just say "Hell no - if you have issues with it, you need to work with people to get rid of the BKL rather than cluge around it". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 May 2008 11:10
On Wed, 7 May 2008, Linus Torvalds wrote: > > Quite frankly, maybe we _need_ to have a bad BKL for those to ever get > fixed. As it was, people worked on trying to make the BKL behave better, > and it was a failure. Rather than spend the effort on trying to make it > work better (at a horrible cost), why not just say "Hell no - if you have > issues with it, you need to work with people to get rid of the BKL > rather than cluge around it". Put another way: if we had introduced the BKL-as-semaphore with a known 40% performance drop in AIM7, I would simply never ever have accepted the patch in the first place, regardless of _any_ excuses. Performance is a feature too. Now, just because the code is already merged should not be an excuse for it then being shown to be bad. It's not a valid excuse to say "but we already merged it, so we can't unmerge it". We sure as hell _can_ unmerge it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |