Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: OUQsGR6tpdzz/5H/mYCGsSJXp7K0u1QY/NsNCtbyYowNNybb3KMZYes/DIX5Tx2X2wPfUf2ykm
 UZz4tO6FJxJw==
IronPort-SDR: 8BmBhJK0aFEb0A6dirM7HWR6n/PN+I26Mj1zqT9+2QxNRGj+RRG97Us1wmQJfhse4G4wMbbI5k
 Ju5YeNZe0CTQ==
From:   Andi Kleen <ak@linux.intel.com>
To:     Alex Kogan <alex.kogan@oracle.com>
Cc:     linux@armlinux.org.uk, peterz@infradead.org, mingo@redhat.com,
        will.deacon@arm.com, arnd@arndb.de, longman@redhat.com,
        linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, tglx@linutronix.de, bp@alien8.de,
        hpa@zytor.com, x86@kernel.org, guohanjun@huawei.com,
        jglauber@marvell.com, steven.sistare@oracle.com,
        daniel.m.jordan@oracle.com, dave.dice@oracle.com
Subject: Re: [PATCH v14 4/6] locking/qspinlock: Introduce starvation avoidance into CNA
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
        <20210401153156.1165900-5-alex.kogan@oracle.com>
        <87mtu2vhzz.fsf@linux.intel.com>
Date:   Mon, 12 Apr 2021 23:12:13 -0700
In-Reply-To: <87mtu2vhzz.fsf@linux.intel.com> (Andi Kleen's message of "Mon,
        12 Apr 2021 23:03:12 -0700")
Message-ID: <87im4qvhky.fsf@linux.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Andi Kleen <ak@linux.intel.com> writes:

> Alex Kogan <alex.kogan@oracle.com> writes:
>>  
>> +	numa_spinlock_threshold=	[NUMA, PV_OPS]
>> +			Set the time threshold in milliseconds for the
>> +			number of intra-node lock hand-offs before the
>> +			NUMA-aware spinlock is forced to be passed to
>> +			a thread on another NUMA node.	Valid values
>> +			are in the [1..100] range. Smaller values result
>> +			in a more fair, but less performant spinlock,
>> +			and vice versa. The default value is 10.
>
> ms granularity seems very coarse grained for this. Surely
> at some point of spinning you can afford a ktime_get? But ok.

Actually thinking about it more using jiffies is likely broken
anyways because if the interrupts are disabled and the CPU
is running the main timer interrupts they won't increase.

cpu_clock (better than ktime_get) or sched_clock would work.

-Andi