2022-06-03 14:16:03

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH V15 10/24] LoongArch: Add other common headers

On Fri, Jun 3, 2022 at 3:40 PM Jason A. Donenfeld <[email protected]> wrote:
> On Fri, Jun 03, 2022 at 03:20:39PM +0800, Huacai Chen wrote:
> > diff --git a/arch/loongarch/include/asm/timex.h b/arch/loongarch/include/asm/timex.h
>
> "Currently only used on SMP for scheduling" isn't quite correct. It's
> also used by random_get_entropy(). And anything else that uses
> get_cycles() for, e.g., benchmarking, might use it too.
>
> You wrote also, "we know that all SMP capable CPUs have cycle counters",
> so if I gather from this statement that some !SMP CPUs don't have a
> cycle counter, though some do. If that's a correct supposition, then
> you may need to rewrite this file to be something like:

The file is based on the mips version that deals with a variety of
implementations
and has the same comment.

I assume the loongarch chips all behave the same way here, and won't need
a special case for non-SMP.

Arnd


2022-06-03 19:54:24

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: [PATCH V15 10/24] LoongArch: Add other common headers

Hi Arnd,

On Fri, Jun 03, 2022 at 03:55:27PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 3, 2022 at 3:40 PM Jason A. Donenfeld <[email protected]> wrote:
> > On Fri, Jun 03, 2022 at 03:20:39PM +0800, Huacai Chen wrote:
> > > diff --git a/arch/loongarch/include/asm/timex.h b/arch/loongarch/include/asm/timex.h
> >
> > "Currently only used on SMP for scheduling" isn't quite correct. It's
> > also used by random_get_entropy(). And anything else that uses
> > get_cycles() for, e.g., benchmarking, might use it too.
> >
> > You wrote also, "we know that all SMP capable CPUs have cycle counters",
> > so if I gather from this statement that some !SMP CPUs don't have a
> > cycle counter, though some do. If that's a correct supposition, then
> > you may need to rewrite this file to be something like:
>
> The file is based on the mips version that deals with a variety of
> implementations
> and has the same comment.
>
> I assume the loongarch chips all behave the same way here, and won't need
> a special case for non-SMP.

Oh good. In that case, the code is fine and I suppose the comment could
just be removed.

Jason

2022-06-06 05:33:13

by WANG Xuerui

[permalink] [raw]
Subject: Re: [PATCH V15 10/24] LoongArch: Add other common headers

On 6/3/22 22:01, Jason A. Donenfeld wrote:
> Hi Arnd,
>
> On Fri, Jun 03, 2022 at 03:55:27PM +0200, Arnd Bergmann wrote:
>> On Fri, Jun 3, 2022 at 3:40 PM Jason A. Donenfeld <[email protected]> wrote:
>>> On Fri, Jun 03, 2022 at 03:20:39PM +0800, Huacai Chen wrote:
>>>> diff --git a/arch/loongarch/include/asm/timex.h b/arch/loongarch/include/asm/timex.h
>>> "Currently only used on SMP for scheduling" isn't quite correct. It's
>>> also used by random_get_entropy(). And anything else that uses
>>> get_cycles() for, e.g., benchmarking, might use it too.
>>>
>>> You wrote also, "we know that all SMP capable CPUs have cycle counters",
>>> so if I gather from this statement that some !SMP CPUs don't have a
>>> cycle counter, though some do. If that's a correct supposition, then
>>> you may need to rewrite this file to be something like:
>> The file is based on the mips version that deals with a variety of
>> implementations
>> and has the same comment.
>>
>> I assume the loongarch chips all behave the same way here, and won't need
>> a special case for non-SMP.
> Oh good. In that case, the code is fine and I suppose the comment could
> just be removed.

In addition, the rdtime family of instructions is in fact guaranteed to
be available on LoongArch; LoongArch's subsets all contain them, even
the 32-bit "Primary" subset intended for university teaching -- they
provide the rdtimeh.w and rdtimel.w pair of instructions that access the
same 64-bit counter. So I think the comments are probably just leftovers
from a very early port; the LoongArch development started way before it
was publicized.

And yes, the comment block re get_cycles usage can be removed altogether.