> On Apr 13, 2021, at 8:03 AM, Peter Zijlstra wrote:
>
> On Thu, Apr 01, 2021 at 11:31:54AM -0400, Alex Kogan wrote:
>
>> @@ -49,13 +55,33 @@ struct cna_node {
>> u16 real_numa_node;
>> u32 encoded_tail; /* self */
>> u32
On 4/14/21 1:26 PM, Andi Kleen wrote:
The CNA code, if enabled, will be in vmlinux, not in a kernel module. As a
result, I think a module parameter will be no different from a kernel
command line parameter in this regard.
You can still change it in /sys at runtime, even if it's in the vmlinux.
> The CNA code, if enabled, will be in vmlinux, not in a kernel module. As a
> result, I think a module parameter will be no different from a kernel
> command line parameter in this regard.
You can still change it in /sys at runtime, even if it's in the vmlinux.
-Andi
On 4/13/21 5:01 PM, Alex Kogan wrote:
Hi, Andi.
Thanks for your comments!
On Apr 13, 2021, at 2:03 AM, Andi Kleen wrote:
Alex Kogan writes:
+ numa_spinlock_threshold=[NUMA, PV_OPS]
+ Set the time threshold in milliseconds for the
+
> On Apr 13, 2021, at 5:22 PM, Andi Kleen wrote:
>
>>> ms granularity seems very coarse grained for this. Surely
>>> at some point of spinning you can afford a ktime_get? But ok.
>> We are reading time when we are at the head of the (main) queue, but
>> don’t have the lock yet. Not sure about
> > ms granularity seems very coarse grained for this. Surely
> > at some point of spinning you can afford a ktime_get? But ok.
> We are reading time when we are at the head of the (main) queue, but
> don’t have the lock yet. Not sure about the latency of ktime_get(), but
> anything reasonably
Hi, Andi.
Thanks for your comments!
> On Apr 13, 2021, at 2:03 AM, Andi Kleen wrote:
>
> Alex Kogan writes:
>>
>> +numa_spinlock_threshold=[NUMA, PV_OPS]
>> +Set the time threshold in milliseconds for the
>> +number of intra-node lock
7 matches
Mail list logo
