From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Rongwei Wang <rongwei.wang@linux.alibaba.com>,
Christoph Lameter <cl@linux.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH v2 5/5] mm/slub: simplify __cmpxchg_double_slab() and slab_[un]lock()
Date: Wed, 24 Aug 2022 18:31:14 +0200 [thread overview]
Message-ID: <YwZSUpYY9l442Lxr@linutronix.de> (raw)
In-Reply-To: <YwX8VPptgCLkuP6i@hyeyoo>
On 2022-08-24 19:24:20 [+0900], Hyeonggon Yoo wrote:
> I'm not familiar with PREEMPT_RT preemption model so not sure I'm following.
>
> 1) Does "interrupts are threaded on RT" mean processing _most_ (all handlers
> that did not specified IRQF_NO_THREAD) of interrupts are delayed to irq threads
> and processed later in process context, and the kernel *never* use
> spinlock_t, local_lock_t that does not disable interrupts (and sleep) on RT
> in hardware/software interrupt context?
All non-threaded interrupts (or everything in hardirq context) must not
allocate (even with GFP_ATOMIC) or free memory on PREEMPT_RT. This is
policy. If you refer by "software interrupt" to softirqs then they can
allocate memory since softirq is also threaded.
> BTW Is there a good documentation/papers on PREEMPT_RT preemption model?
> I tried to find but only found Documentation/locking/locktypes.rst :(
What is it, that you are looking for? But the locking description is
good ;)
> Thanks!
>
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > Acked-by: David Rientjes <rientjes@google.com>
Sebastian
next prev parent reply other threads:[~2022-08-24 16:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 17:03 [PATCH v2 0/5] mm/slub: fix validation races and cleanup locking Vlastimil Babka
2022-08-23 17:03 ` [PATCH v2 1/5] mm/slub: move free_debug_processing() further Vlastimil Babka
2022-08-23 17:03 ` [PATCH v2 2/5] mm/slub: restrict sysfs validation to debug caches and make it safe Vlastimil Babka
2022-08-24 4:41 ` Hyeonggon Yoo
2022-08-23 17:03 ` [PATCH v2 3/5] mm/slub: remove slab_lock() usage for debug operations Vlastimil Babka
2022-08-23 17:03 ` [PATCH v2 4/5] mm/slub: convert object_map_lock to non-raw spinlock Vlastimil Babka
2022-08-24 15:53 ` Sebastian Andrzej Siewior
2022-08-23 17:04 ` [PATCH v2 5/5] mm/slub: simplify __cmpxchg_double_slab() and slab_[un]lock() Vlastimil Babka
2022-08-24 10:24 ` Hyeonggon Yoo
2022-08-24 11:51 ` Vlastimil Babka
2022-08-24 12:45 ` Hyeonggon Yoo
2022-08-24 16:31 ` Sebastian Andrzej Siewior [this message]
2022-08-24 13:04 ` Hyeonggon Yoo
2022-08-25 12:41 ` Vlastimil Babka
2022-08-24 16:25 ` Sebastian Andrzej Siewior
2022-08-25 12:59 ` Vlastimil Babka
2022-08-25 7:51 ` [PATCH 6/5] slub: Make PREEMPT_RT support less convoluted Sebastian Andrzej Siewior
2022-08-25 8:41 ` Vlastimil Babka
2022-08-25 8:49 ` Hyeonggon Yoo
2022-08-25 13:16 ` [PATCH v2 0/5] mm/slub: fix validation races and cleanup locking Vlastimil Babka
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=YwZSUpYY9l442Lxr@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=42.hyeyoo@gmail.com \
--cc=cl@linux.com \
--cc=efault@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rongwei.wang@linux.alibaba.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
/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.