Re: [PATCH][RFC] parisc: Use ldcw,co on uniprocessor machines only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11.12.19 22:29, John David Anglin wrote:
> On 2019-12-11 3:16 p.m., Helge Deller wrote:
>> Up to now we tried to optimize the ldcw usage by using the coherent
>> completer of this command, which operates on the cache (instead of
>> memory) and thus might speed up things, and which was enabled by default
>> on our 64bit kernel build.
>>
>> But we still see runtime locking problems, so this patch changes it back
>> to use ldcw for 32- and 64-bit kernels, and live-patches it at runtime
>> to use the coherent completer when running on a uniprocessor machine.
> I'm not convinced this is the problem.  Nominally, every PA 2.0 machine that we support is coherent.
> Is there evidence that this actually helps?  I did a test where I switched "ldcw,co" to "ldcw" and
> didn't find a significant difference.  So, I left the default assumption that most PA 2.0 machines
> are coherent in gcc.
>
> I'm seeing different behavior for pthread_mutex_lock/pthread_mutex_unlock with different
> glibc versions.  The locking issues also seem to vary from one kernel version to the next.
>
> I don't know that we can blame the two build failures of acl2_8.1dfsg-6 on phantom on a
> locking issue, but phantom failed twice at the same pwasoint.  In both cases, cc1 terminated with
> a segmentation fault.  Yet, mx3210 has been chugging away for more than a day on the package.
> It also built -4 and -5.
>
> I don't have a clue what's really wrong but I suspect the slowness of our locking infrastructure
> is what exposes these issues.
>
> I've seen one issue in user space where a pointer to a mutex got corrupted in apt-cacher-ng.
> If I remember correctly, the LWS locking code was spinning with a pointer value of 0x12.  I think
> the code should have faulted but the thread stuck.  Had to systemctl restart apt-cacher-ng.

Dave, thanks for your feedback!
I'm neither convinced that this helps, nor did I tested it any further than just booting.
My main concern is the stuck kernel threads which happen seldom on the bigger debian buildd
servers.
For now I'll not apply my patch for upstream kernels, but will keep it in patchwork.

Helge




[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux