Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1192425 > unrolled thread

Re: linux-next: build failure after merge of the akpm-current tree

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1192425 — Re: linux-next: build failure after merge of the akpm-current tree

On Fri, Jul 24, 2015 at 04:09:02PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 24, 2015 at 01:16:05PM -0700, Davidlohr Bueso wrote:
> > On Fri, 2015-07-24 at 15:33 +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > allnoconfig) failed like this:
> > > 
> > > mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
> > > vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
> > > vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
> > > mm/built-in.o: In function `unregister_shrinker':
> > > (.text+0xfa60): undefined reference to `synchronize_srcu'
> > > mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
> > > 
> > > Caused by commit
> > > 
> > >   dab937da82f9 ("mm: srcu-ify shrinkers")
> > > 
> > > I have reverted that commit for today.
> > 
> > Adding paulmck.
> > 
> > I'm not entirely sure what is the fix here. Paul G also reported it
> > failing for arm. I was able to reproduce with powerpc, and the following
> > fixes the issue, but I doubt it is the correct way to address this. The
> > idea was based on how we do it for x86.
> > 
> > Also, having SRCU in mm is, lets say, more than convenient, beyond
> > MMU_NOTIFIERS which explicitly selects SRCU.
> > 
> > Paul?
> 
> SRCU was made optional as part of the kernel tinification project,
> so adding Josh on CC.  The hope would be that the feature needing SRCU
> could add the "select" rather than having major architectures doing so.
> 
> I guess if SRCU is needed everywhere, it is needed everywhere, but...

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.

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.

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.

- Josh Triplett
--
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/

[toc] | [next] | [standalone]

#1192427

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/

[toc] | [prev] | [next] | [standalone]

#1193530

On Mon, Jul 27, 2015 at 01:31:33PM -0700, Andrew Morton wrote:
> On Mon, 27 Jul 2015 13:27:58 -0700 josh@joshtriplett.org wrote:
> 
> > I agree with that.  I'm wondering if, rather than making the
> > SRCU-ification optional, shrinkers themselves could just be optional.
> > Unless I'm badly misunderstanding what shrinkers do, they seem like a
> > perfect example of something that could be omitted with little to no
> > impact.  (Stub them out, make them never called, and if you run out of
> > memory just be unhappy.  Ditto for the oom-killer, which really ought to
> > be optional.)
> 
> The shrinkers do important stuff ;) "find /" will consume large amounts
> of memory for inode and dentry caches.  The shrinkers are how we free
> that up again.

*Ah*, I see.  I misunderstood their purpose, and I didn't realize that
was one of the cases they covered.  While that might be possible to
reduce, it doesn't sound like it can go away entirely. :)

- Josh Triplett
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web