From: Christoph Hellwig <hch@lst.de>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Joel Fernandes <joelaf@google.com>,
Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jisheng Zhang <jszhang@marvell.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
John Dias <joaodias@google.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
linux-rt-users@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH 4/7] mm: defer vmalloc from atomic context
Date: Mon, 7 Nov 2016 16:09:47 +0100 [thread overview]
Message-ID: <20161107150947.GA11279@lst.de> (raw)
In-Reply-To: <a40cccff-3a6e-b0be-5d06-bac6cdb0e1e6@virtuozzo.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Joel Fernandes <joelaf@google.com>,
Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jisheng Zhang <jszhang@marvell.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
John Dias <joaodias@google.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
linux-rt-users@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH 4/7] mm: defer vmalloc from atomic context
Date: Mon, 7 Nov 2016 16:09:47 +0100 [thread overview]
Message-ID: <20161107150947.GA11279@lst.de> (raw)
In-Reply-To: <a40cccff-3a6e-b0be-5d06-bac6cdb0e1e6@virtuozzo.com>
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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-11-07 15:09 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-22 15:17 reduce latency in __purge_vmap_area_lazy Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-22 15:17 ` [PATCH 1/7] mm: remove free_unmap_vmap_area_noflush Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-22 15:17 ` [PATCH 2/7] mm: remove free_unmap_vmap_area_addr Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-22 15:17 ` [PATCH 3/7] mm: refactor __purge_vmap_area_lazy Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-22 15:17 ` [PATCH 4/7] mm: defer vmalloc from atomic context Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-24 15:44 ` Andrey Ryabinin
2016-10-24 15:44 ` Andrey Ryabinin
2016-10-24 15:44 ` Andrey Ryabinin
2016-11-05 3:43 ` Joel Fernandes
2016-11-05 3:43 ` Joel Fernandes
2016-11-07 15:01 ` Andrey Ryabinin
2016-11-07 15:01 ` Andrey Ryabinin
2016-11-07 15:01 ` Andrey Ryabinin
2016-11-07 15:09 ` Christoph Hellwig [this message]
2016-11-07 15:09 ` Christoph Hellwig
2016-11-08 15:03 ` Andrey Ryabinin
2016-11-08 15:03 ` Andrey Ryabinin
2016-11-08 15:03 ` Andrey Ryabinin
2016-11-08 15:05 ` [PATCH 1/3] mm/vmalloc: add vfree_atomic() Andrey Ryabinin
2016-11-08 15:05 ` Andrey Ryabinin
2016-11-08 15:05 ` Andrey Ryabinin
2016-11-08 15:05 ` [PATCH 2/3] kernel/fork: use vfree_atomic() to free thread stack Andrey Ryabinin
2016-11-08 15:05 ` Andrey Ryabinin
2016-11-08 15:05 ` Andrey Ryabinin
2016-11-08 15:05 ` [PATCH 3/3] x86/ldt: use vfree_atomic() to free ldt entries Andrey Ryabinin
2016-11-08 15:05 ` Andrey Ryabinin
2016-11-08 15:05 ` Andrey Ryabinin
2016-11-07 16:50 ` [PATCH 4/7] mm: defer vmalloc from atomic context Joel Fernandes
2016-11-07 16:50 ` Joel Fernandes
2016-10-22 15:17 ` [PATCH 5/7] mm: mark all calls into the vmalloc subsystem as potentially sleeping Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-22 15:17 ` [PATCH 6/7] mm: turn vmap_purge_lock into a mutex Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
2016-10-22 15:17 ` [PATCH 7/7] mm: add preempt points into __purge_vmap_area_lazy Christoph Hellwig
2016-10-22 15:17 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161107150947.GA11279@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=chris@chris-wilson.co.uk \
--cc=joaodias@google.com \
--cc=joelaf@google.com \
--cc=jszhang@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=luto@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.