Re: [PATCH 4/7] mm: defer vmalloc from atomic context

From	Christoph Hellwig <hch@lst.de>
Newsgroups	linux.kernel
Subject	Re: [PATCH 4/7] mm: defer vmalloc from atomic context
Date	2016-11-07 16:20 +0100
Message-ID	<sATSh-4Pz-5@gated-at.bofh.it> (permalink)
References	<sv6fv-585-13@gated-at.bofh.it> <sv6fw-585-25@gated-at.bofh.it> <sA09r-2Ft-5@gated-at.bofh.it> <sA09r-2Ft-3@gated-at.bofh.it> <sATSh-4Pz-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Mon, Nov 07, 2016 at 06:01:45PM +0300, Andrey Ryabinin wrote:
> > So because in_atomic doesn't work for !CONFIG_PREEMPT kernels, can we
> > always defer the work in these cases?
> > 
> > So for non-preemptible kernels, we always defer:
> > 
> > if (!IS_ENABLED(CONFIG_PREEMPT) || in_atomic()) {
> >   // defer
> > }
> > 
> > Is this fine? Or any other ideas?
> > 
> 
> What's wrong with my idea?
> We can add vfree_in_atomic() and use it to free vmapped stacks
> and for any other places where vfree() used 'in_atomict() && !in_interrupt()' context.

I somehow missed the mail, sorry.  That beeing said always defer is
going to suck badly in terms of performance, so I'm not sure it's an all
that good idea.

vfree_in_atomic sounds good, but I wonder if we'll need to annotate
more callers than just the stacks.  I'm fairly bust this week, do you
want to give that a spin?  Otherwise I'll give it a try towards the
end of this week or next week.

Thread

Re: [PATCH 4/7] mm: defer vmalloc from atomic context Joel Fernandes <joelaf@google.com> - 2016-11-05 04:50 +0100
  Re: [PATCH 4/7] mm: defer vmalloc from atomic context Christoph Hellwig <hch@lst.de> - 2016-11-07 16:20 +0100
  Re: [PATCH 4/7] mm: defer vmalloc from atomic context Joel Fernandes <joelaf@google.com> - 2016-11-07 18:00 +0100

csiph-web