Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 23 Jun 2023 10:17:56 +0200
From:   Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To:     John Johansen <john.johansen@canonical.com>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Swapnil Sapkal <Swapnil.Sapkal@amd.com>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
        Aaron Lu <aaron.lu@intel.com>, x86@kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [tip: sched/core] sched: Fix performance regression introduced
 by mm_cid
Message-ID: <20230623081756.vVHIjkC9@linutronix.de>
References: <09e0f469-a3f7-62ef-75a1-e64cec2dcfc5@amd.com>
 <20230620091139.GZ4253@hirez.programming.kicks-ass.net>
 <44428f1e-ca2c-466f-952f-d5ad33f12073@amd.com>
 <3e9eaed6-4708-9e58-c80d-143760d6b23a@efficios.com>
 <ddbd1564-8135-5bc3-72b4-afb7c6e9caba@amd.com>
 <a73761e4-b791-e9a2-a276-e1551628e33b@efficios.com>
 <6c693e3b-b941-9acf-6821-179e7a7fe2b8@efficios.com>
 <f94cd9fa-1a83-1f54-0259-123fcd86d549@canonical.com>
 <20230623063726.ejuc6v9D@linutronix.de>
 <ed287d2f-5b53-dffb-dec3-e5b28fa70a52@canonical.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ed287d2f-5b53-dffb-dec3-e5b28fa70a52@canonical.com>
Precedence: bulk

On 2023-06-23 00:35:29 [-0700], John Johansen wrote:
> > 
> iirc the difference with the earlier version, is in the put case. Where in
> the earlier version, if there was lock contention the buffer would always
> get pushed onto the percpu list. With some debug patches on top we
> saw some degenerate cases where this would result in percpu lists that
> had excessive buffers on them.
> 
> So this version added a condition to force putting the buffer back
> in to the global pool if the percpu list already has 2 buffers
> cached on it.

So none of the versions perform memory allocation/ deallocation in a
preempt disabled section so it is fine from PREEMPT_RT point of view.

Sebastian