Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1192427
| From | Davidlohr Bueso <dave@stgolabs.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: linux-next: build failure after merge of the akpm-current tree |
| Date | 2015-07-25 23:30 +0200 |
| Message-ID | <pQfb3-83S-1@gated-at.bofh.it> (permalink) |
| References | <pPDS9-4LC-3@gated-at.bofh.it> <pPRBM-7TR-11@gated-at.bofh.it> <pPUgi-3lD-9@gated-at.bofh.it> <pQdLY-5VI-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: linux-next: build failure after merge of the akpm-current tree Josh Triplett <josh@joshtriplett.org> - 2015-07-25 22:00 +0200
Re: linux-next: build failure after merge of the akpm-current tree Davidlohr Bueso <dave@stgolabs.net> - 2015-07-25 23:30 +0200
Re: linux-next: build failure after merge of the akpm-current tree Josh Triplett <josh@joshtriplett.org> - 2015-07-28 00:20 +0200
csiph-web