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

josh
2015-07-27T20:27:58Z

On Mon, Jul 27, 2015 at 01:03:12PM -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
>
> > > 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.
> >
> > What other mm functionality plans to use SRCU?
> >
> > Among other things, no-mmu builds might still be able to omit it.
>
> Yup.
>
> It's pretty trivial to make the shrinker srcuification be a
> Kconfigurable thing. A few little helper functions and we're done.
> That way, non-SMP kernels can use the plain old rwsem if so desired.
>
> otoh it's better to use the same mechanism on all kernels for reasons
> of testing coverage, maintenance cost, etc.

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.)

- Josh Triplett