Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1192427
| Path | csiph.com!aioe.org!bofh.it!news.nic.it!robomod |
|---|---|
| From | Davidlohr Bueso <dave@stgolabs.net> |
| Newsgroups | linux.kernel |
| Subject | Re: linux-next: build failure after merge of the akpm-current tree |
| Date | Sat, 25 Jul 2015 23:30:01 +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> |
| X-Original-To | Josh Triplett <josh@joshtriplett.org> |
| Content-Type | text/plain; charset="UTF-8" |
| X-Mailer | Evolution 3.12.11 |
| MIME-Version | 1.0 |
| Content-Transfer-Encoding | 7bit |
| Sender | robomod@news.nic.it |
| List-ID | <linux-kernel.vger.kernel.org> |
| X-Mailing-List | linux-kernel@vger.kernel.org |
| Approved | robomod@news.nic.it |
| Lines | 35 |
| Organization | linux.* mail to news gateway |
| X-Original-Cc | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Stephen Rothwell <sfr@canb.auug.org.au>, Andrew Morton <akpm@linux-foundation.org>, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org |
| X-Original-Date | Sat, 25 Jul 2015 14:24:02 -0700 |
| X-Original-Message-ID | <1437859442.3298.68.camel@stgolabs.net> |
| X-Original-References | <20150724153334.543cfc7b@canb.auug.org.au> <1437768965.3298.52.camel@stgolabs.net> <20150724230902.GQ3717@linux.vnet.ibm.com> <20150725194739.GA9753@x> |
| X-Original-Sender | linux-kernel-owner@vger.kernel.org |
| Xref | aioe.org linux.kernel:1192427 |
Show key headers only | View raw
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