[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c8f82c3-1296-ca28-0a21-6c5467ac2e3e@amd.com>
Date: Sat, 4 Feb 2023 23:48:30 +0530
From: Raghavendra K T <raghavendra.kt@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Ingo Molnar <mingo@...hat.com>, Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>, rppt@...nel.org,
Bharata B Rao <bharata@....com>,
Disha Talreja <dishaa.talreja@....com>
Subject: Re: [PATCH V2 2/3] sched/numa: Enhance vma scanning logic
On 2/3/2023 4:57 PM, Peter Zijlstra wrote:
> On Fri, Feb 03, 2023 at 12:15:48PM +0100, Peter Zijlstra wrote:
>
>>> +static inline void vma_set_active_pid_bit(struct vm_area_struct *vma)
>>> +{
>>> + unsigned int active_pid_bit;
>>> +
>>> + if (vma->numab) {
>>> + active_pid_bit = current->pid % BITS_PER_LONG;
>>> + vma->numab->accessing_pids |= 1UL << active_pid_bit;
>>> + }
>>> +}
>>
>> Perhaps:
>>
>> if (vma->numab)
>> __set_bit(current->pid % BITS_PER_LONG, &vma->numab->pids);
>>
>> ?
>>
>> Or maybe even:
>>
>> bit = current->pid % BITS_PER_LONG;
>> if (vma->numab && !__test_bit(bit, &vma->numab->pids))
>> __set_bit(bit, &vma->numab->pids);
>>
>
> The alternative to just taking the low n bits is to use:
>
> hash_32(current->pid, BITS_PER_LONG)
>
> That mixes things up a bit.
Good idea, when we have workloads that creates lesser number of threads
faster, current solution might have been simpler, but with thread
creation that happens over period of time hash function mixes and avoids
collision. will experiment with this option.
Powered by blists - more mailing lists