On Sat, 2015-07-25 at 12:47 -0700, Josh Triplett wrote: > I certainly agree that it doesn't make sense to make all architectures > select SRCU, if an unremovable core kernel feature uses SRCU. If > possible, I'd really like to avoid seeing SRCU become mandatory again, > though. I find it very strange that srcu is not taken for granted like rcu is, or even regular locking primitives. How much overhead does srcu add? > Is there any chance at all of the shrinker mechanism becoming optional? > At first glance, it seems reasonably separate from the rest of mm, in > that if it didn't exist and shrinking didn't happen, the rest of mm > still works. If that happened, MM_SHRINKER could select SRCU. Some mm functionality might very possibly rely on srcu in the future if we expect any chances of scaling, ie: faults. So I'd rather not take a short term solution here, as we'll probably be discussing this again otherwise. > If that's not possible, then for the moment, I'd suggest making a hidden > symbol MM_SHRINKER that's always y and does "select SRCU", to preserve > SRCU's modularity for the moment while not forcing every architecture to > select it. This is _very_ hacking. While tinyfication has its uses and applications, I'd rather not have it in the way of normal kernels. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
