Re: [RFC PATCH] sched: Fix performance regression introduced by mm_cid

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2023-04-04 05:10, Peter Zijlstra wrote:
> On Tue, Apr 04, 2023 at 10:57:49AM +0200, Peter Zijlstra wrote:
>>
>> Sorry for being a little late to the party.
>>
>> On Mon, Apr 03, 2023 at 02:13:42PM -0400, Mathieu Desnoyers wrote:
>>
>>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>>> index 0722859c3647..21466fdc4dc6 100644
>>> --- a/include/linux/mm_types.h
>>> +++ b/include/linux/mm_types.h
>>> @@ -609,6 +609,14 @@ struct mm_struct {
>>>   		 * were being concurrently updated by the updaters.
>>>   		 */
>>>   		raw_spinlock_t cid_lock;
>>> +		/**
>>> +		 * @pcpu_cid: Per-cpu current cid.
>>> +		 *
>>> +		 * Keep track of the currently allocated mm_cid for each cpu.
>>> +		 * The per-cpu mm_cid values are serialized by their respective
>>> +		 * runqueue locks.
>>> +		 */
>>> +		int __percpu *pcpu_cid;
>>
>> This *might* be a problem... Consider running *many* single threaded
>> processes, this could exhaust the limited per-cpu storage (32bit) or use
>> excessive memory on large CPU systems.
>>
>> Consider having to allocate per-cpu storage on a 4K CPU system while
>> only running single threaded processes -- but *LOTS* of them..
> 
> Ah, mm_struct::rss_stat[] beat us and set precedent, so not our problem I
> suppose :-)

Yes, exactly. When I've seen that mm_struct::rss_stat[] did not care 
about having per-mm/per-cpu data, I went the same way.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com