All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Minchan Kim <minchan@kernel.org>,
	linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH] mm/zsmalloc: Replace bit spinlock and get_cpu_var() usage.
Date: Tue, 28 Sep 2021 15:47:23 -0700	[thread overview]
Message-ID: <20210928154723.1b0577818143734653d9b129@linux-foundation.org> (raw)
In-Reply-To: <20210928084419.mkfu62barwrsvflq@linutronix.de>

On Tue, 28 Sep 2021 10:44:19 +0200 Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> From: Mike Galbraith <umgwanakikbuti@gmail.com>
> 
> For efficiency reasons, zsmalloc is using a slim `handle'. The value is
> the address of a memory allocation of 4 or 8 bytes depending on the size
> of the long data type. The lowest bit in that allocated memory is used
> as a bit spin lock.
> The usage of the bit spin lock is problematic because with the bit spin
> lock held zsmalloc acquires a rwlock_t and spinlock_t which are both
> sleeping locks on PREEMPT_RT and therefore must not be acquired with
> disabled preemption.
> 
> Extend the handle to struct zsmalloc_handle which holds the old handle as
> addr and a spinlock_t which replaces the bit spinlock. Replace all the
> wrapper functions accordingly.
> 
> The usage of get_cpu_var() in zs_map_object() is problematic because
> it disables preemption and makes it impossible to acquire any sleeping
> lock on PREEMPT_RT such as a spinlock_t.
> Replace the get_cpu_var() usage with a local_lock_t which is embedded
> struct mapping_area. It ensures that the access the struct is
> synchronized against all users on the same CPU.
> 
> This survived LTP testing.

Rather nasty with all the ifdefs and two different locking approaches
to be tested.  What would be the impact of simply switching to the new
scheme for all configs?

Which is identical to asking "what is the impact of switching to the new
scheme for PREEMPT_RT"!  Which is I think an important thing for the
changelog to address?



  reply	other threads:[~2021-09-28 22:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23 17:01 [PATCH] mm: Disable zsmalloc on PREEMPT_RT Sebastian Andrzej Siewior
2021-09-23 23:06 ` Minchan Kim
2021-09-24  7:08   ` Sebastian Andrzej Siewior
2021-09-28  8:44   ` [PATCH] mm/zsmalloc: Replace bit spinlock and get_cpu_var() usage Sebastian Andrzej Siewior
2021-09-28 22:47     ` Andrew Morton [this message]
2021-09-29  2:11       ` Mike Galbraith
2021-09-29  7:23       ` Sebastian Andrzej Siewior
2021-09-29 19:09         ` Minchan Kim
2021-09-30  6:42           ` Sebastian Andrzej Siewior

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=20210928154723.1b0577818143734653d9b129@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=efault@gmx.de \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=umgwanakikbuti@gmail.com \
    /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.