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

[Davidlohr Bueso]

On Mon, 2015-07-27 at 13:03 -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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?

Right now I have (unpublished) patches that use srcu as a way to avoid
mmap_sem when faulting across the entire path. Previous alternatives
also use it, as ie, can involve IO and lots of other sleeping
operations. Yes, you can argue that they're not published all you want,
but I'm talking beyond my specific use case. Linux VM is known to scale,
why should we hide a core scalability tool from it?

> > Among other things, no-mmu builds might still be able to omit it.
> 
> Yup.

Makes sense.

> 
> 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.
> 
> The mm-srcu-ify-shrinkers.patch changelog is suspiciously lacking in
> evidence-of-benefit.  We could just drop it?

That's up to you, but I feel we should have srcu available in mm.
Dropping this particular patch is only a band-aid, imo.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/