linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
@ 2018-10-24 20:42 Palmer Dabbelt
  2018-10-24 20:42 ` Palmer Dabbelt
  2018-10-26  1:12 ` Linus Torvalds
  0 siblings, 2 replies; 14+ messages in thread
From: Palmer Dabbelt @ 2018-10-24 20:42 UTC (permalink / raw)
  To: linux-riscv

The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:

  Linux 4.19 (2018-10-22 07:37:37 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.20-mw0

for you to fetch changes up to d26c4bbf992463c043fdee4b3e5efa3f08990862:

  RISC-V: SMP cleanup and new features (2018-10-22 17:41:43 -0700)

----------------------------------------------------------------
RISC-V Patches for the 4.20 Merge Window, Part 1

This patch set contains a lot (at least, for me) of improvements to the
RISC-V kernel port:

* The removal of some cacheinfo values that were bogus.
* On systems with F but without D the kernel will not show the F
  extension to userspace, as it isn't actually supported.
* Support for futexes.
* Removal of some unused code.
* Cleanup of some menuconfig entries.
* Support for systems without a floating-point unit, and for building
  kernels that will never use the floating-point unit.
* More fixes to the RV32I port, which regressed again.  It's really time
  to get this into a regression test somewhere so I stop breaking it.
  Thanks to Zong for resurrecting it again!
* Various fixes that resulted from a year old review of our original
  patch set that I finally got around to.
* Various improvements to SMP support, largely based around having
  switched to logical hart numbering, as well as some interrupt
  improvements.  This one is in the same patch set as above, thanks to
  Atish for sheparding everything though as my patch set was a bit of a
  mess.

I'm pretty sure this is our largest patch set since the original kernel
contribution, and it's certainly the one with the most contributors.
While I don't have anything else I know I'm going to submit for the
merge window, I would be somewhat surprised if I didn't screw anything
up.

[Since writing this I've found at least one more patch set for next week.]

Thanks for the help, everyone!

----------------------------------------------------------------
Alan Kao (5):
      Extract FPU context operations from entry.S
      Refactor FPU code in signal setup/return procedures
      Cleanup ISA string setting
      Allow to disable FPU support
      Auto-detect whether a FPU exists

Anup Patel (3):
      RISC-V: No need to pass scause as arg to do_IRQ()
      RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo
      RISC-V: Show IPI stats

Atish Patra (4):
      RISC-V: Disable preemption before enabling interrupts
      RISC-V: Use WRITE_ONCE instead of direct access
      RISC-V: Add logical CPU indexing for RISC-V
      RISC-V: Use Linux logical CPU number instead of hartid

Christoph Hellwig (1):
      RISC-V: remove the unused return_to_handler export

Jim Wilson (2):
      RISC-V: Add FP register ptrace support for gdb.
      RISC-V: Add futex support.

Masahiro Yamada (1):
      riscv: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig

Nick Kossifidis (1):
      RISC-V: Cosmetic menuconfig changes

Palmer Dabbelt (12):
      RISC-V: Don't set cacheinfo.{physical_line_partition,attributes}
      RISC-V: Filter ISA and MMU values in cpuinfo
      RISC-V: Comment on the TLB flush in smp_callin()
      RISC-V: Provide a cleaner raw_smp_processor_id()
      RISC-V: Rename riscv_of_processor_hart to riscv_of_processor_hartid
      RISC-V: Rename im_okay_therefore_i_am to found_boot_cpu
      RISC-V: Use mmgrab()
      RISC-V: Don't set cacheinfo.{physical_line_partition,attributes}
      RISC-V: Mask out the F extension on systems without D
      riscv: Add support to no-FPU systems
      RISC-V: Fix some RV32 bugs and build failures
      RISC-V: SMP cleanup and new features

Vincent Chen (1):
      RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

Zong Li (4):
      RISC-V: Build tishift only on 64-bit
      RISC-V: Use swiotlb on RV64 only
      lib: Add umoddi3 and udivmoddi4 of GCC library routines
      RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

 arch/riscv/Kconfig                 |  52 ++++++-
 arch/riscv/Kconfig.debug           |  35 -----
 arch/riscv/Makefile                |  21 +--
 arch/riscv/include/asm/Kbuild      |   1 -
 arch/riscv/include/asm/futex.h     | 128 +++++++++++++++
 arch/riscv/include/asm/processor.h |   2 +-
 arch/riscv/include/asm/smp.h       |  47 ++++--
 arch/riscv/include/asm/switch_to.h |  12 +-
 arch/riscv/include/asm/tlbflush.h  |  16 +-
 arch/riscv/include/uapi/asm/elf.h  |   3 +
 arch/riscv/kernel/Makefile         |   1 +
 arch/riscv/kernel/cacheinfo.c      |   7 -
 arch/riscv/kernel/cpu.c            |  87 +++++++++--
 arch/riscv/kernel/cpufeature.c     |  15 ++
 arch/riscv/kernel/entry.S          |  88 -----------
 arch/riscv/kernel/fpu.S            | 106 +++++++++++++
 arch/riscv/kernel/head.S           |   4 +-
 arch/riscv/kernel/irq.c            |  12 +-
 arch/riscv/kernel/mcount.S         |   1 -
 arch/riscv/kernel/process.c        |   6 +-
 arch/riscv/kernel/ptrace.c         |  52 +++++++
 arch/riscv/kernel/setup.c          |  13 ++
 arch/riscv/kernel/signal.c         |  75 +++++----
 arch/riscv/kernel/smp.c            |  82 ++++++++--
 arch/riscv/kernel/smpboot.c        |  46 ++++--
 arch/riscv/lib/Makefile            |   3 +-
 arch/riscv/mm/ioremap.c            |   2 +-
 drivers/clocksource/riscv_timer.c  |  12 +-
 drivers/irqchip/irq-sifive-plic.c  |  10 +-
 lib/Kconfig                        |   3 +
 lib/Makefile                       |   1 +
 lib/udivmoddi4.c                   | 310 +++++++++++++++++++++++++++++++++++++
 lib/umoddi3.c                      |  32 ++++
 33 files changed, 1039 insertions(+), 246 deletions(-)
 create mode 100644 arch/riscv/include/asm/futex.h
 create mode 100644 arch/riscv/kernel/fpu.S
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-24 20:42 [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1 Palmer Dabbelt
@ 2018-10-24 20:42 ` Palmer Dabbelt
  2018-10-26  1:12 ` Linus Torvalds
  1 sibling, 0 replies; 14+ messages in thread
From: Palmer Dabbelt @ 2018-10-24 20:42 UTC (permalink / raw)
  To: Linus Torvalds, Greg KH; +Cc: linux-riscv

The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:

  Linux 4.19 (2018-10-22 07:37:37 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.20-mw0

for you to fetch changes up to d26c4bbf992463c043fdee4b3e5efa3f08990862:

  RISC-V: SMP cleanup and new features (2018-10-22 17:41:43 -0700)

----------------------------------------------------------------
RISC-V Patches for the 4.20 Merge Window, Part 1

This patch set contains a lot (at least, for me) of improvements to the
RISC-V kernel port:

* The removal of some cacheinfo values that were bogus.
* On systems with F but without D the kernel will not show the F
  extension to userspace, as it isn't actually supported.
* Support for futexes.
* Removal of some unused code.
* Cleanup of some menuconfig entries.
* Support for systems without a floating-point unit, and for building
  kernels that will never use the floating-point unit.
* More fixes to the RV32I port, which regressed again.  It's really time
  to get this into a regression test somewhere so I stop breaking it.
  Thanks to Zong for resurrecting it again!
* Various fixes that resulted from a year old review of our original
  patch set that I finally got around to.
* Various improvements to SMP support, largely based around having
  switched to logical hart numbering, as well as some interrupt
  improvements.  This one is in the same patch set as above, thanks to
  Atish for sheparding everything though as my patch set was a bit of a
  mess.

I'm pretty sure this is our largest patch set since the original kernel
contribution, and it's certainly the one with the most contributors.
While I don't have anything else I know I'm going to submit for the
merge window, I would be somewhat surprised if I didn't screw anything
up.

[Since writing this I've found at least one more patch set for next week.]

Thanks for the help, everyone!

----------------------------------------------------------------
Alan Kao (5):
      Extract FPU context operations from entry.S
      Refactor FPU code in signal setup/return procedures
      Cleanup ISA string setting
      Allow to disable FPU support
      Auto-detect whether a FPU exists

Anup Patel (3):
      RISC-V: No need to pass scause as arg to do_IRQ()
      RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo
      RISC-V: Show IPI stats

Atish Patra (4):
      RISC-V: Disable preemption before enabling interrupts
      RISC-V: Use WRITE_ONCE instead of direct access
      RISC-V: Add logical CPU indexing for RISC-V
      RISC-V: Use Linux logical CPU number instead of hartid

Christoph Hellwig (1):
      RISC-V: remove the unused return_to_handler export

Jim Wilson (2):
      RISC-V: Add FP register ptrace support for gdb.
      RISC-V: Add futex support.

Masahiro Yamada (1):
      riscv: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig

Nick Kossifidis (1):
      RISC-V: Cosmetic menuconfig changes

Palmer Dabbelt (12):
      RISC-V: Don't set cacheinfo.{physical_line_partition,attributes}
      RISC-V: Filter ISA and MMU values in cpuinfo
      RISC-V: Comment on the TLB flush in smp_callin()
      RISC-V: Provide a cleaner raw_smp_processor_id()
      RISC-V: Rename riscv_of_processor_hart to riscv_of_processor_hartid
      RISC-V: Rename im_okay_therefore_i_am to found_boot_cpu
      RISC-V: Use mmgrab()
      RISC-V: Don't set cacheinfo.{physical_line_partition,attributes}
      RISC-V: Mask out the F extension on systems without D
      riscv: Add support to no-FPU systems
      RISC-V: Fix some RV32 bugs and build failures
      RISC-V: SMP cleanup and new features

Vincent Chen (1):
      RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

Zong Li (4):
      RISC-V: Build tishift only on 64-bit
      RISC-V: Use swiotlb on RV64 only
      lib: Add umoddi3 and udivmoddi4 of GCC library routines
      RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

 arch/riscv/Kconfig                 |  52 ++++++-
 arch/riscv/Kconfig.debug           |  35 -----
 arch/riscv/Makefile                |  21 +--
 arch/riscv/include/asm/Kbuild      |   1 -
 arch/riscv/include/asm/futex.h     | 128 +++++++++++++++
 arch/riscv/include/asm/processor.h |   2 +-
 arch/riscv/include/asm/smp.h       |  47 ++++--
 arch/riscv/include/asm/switch_to.h |  12 +-
 arch/riscv/include/asm/tlbflush.h  |  16 +-
 arch/riscv/include/uapi/asm/elf.h  |   3 +
 arch/riscv/kernel/Makefile         |   1 +
 arch/riscv/kernel/cacheinfo.c      |   7 -
 arch/riscv/kernel/cpu.c            |  87 +++++++++--
 arch/riscv/kernel/cpufeature.c     |  15 ++
 arch/riscv/kernel/entry.S          |  88 -----------
 arch/riscv/kernel/fpu.S            | 106 +++++++++++++
 arch/riscv/kernel/head.S           |   4 +-
 arch/riscv/kernel/irq.c            |  12 +-
 arch/riscv/kernel/mcount.S         |   1 -
 arch/riscv/kernel/process.c        |   6 +-
 arch/riscv/kernel/ptrace.c         |  52 +++++++
 arch/riscv/kernel/setup.c          |  13 ++
 arch/riscv/kernel/signal.c         |  75 +++++----
 arch/riscv/kernel/smp.c            |  82 ++++++++--
 arch/riscv/kernel/smpboot.c        |  46 ++++--
 arch/riscv/lib/Makefile            |   3 +-
 arch/riscv/mm/ioremap.c            |   2 +-
 drivers/clocksource/riscv_timer.c  |  12 +-
 drivers/irqchip/irq-sifive-plic.c  |  10 +-
 lib/Kconfig                        |   3 +
 lib/Makefile                       |   1 +
 lib/udivmoddi4.c                   | 310 +++++++++++++++++++++++++++++++++++++
 lib/umoddi3.c                      |  32 ++++
 33 files changed, 1039 insertions(+), 246 deletions(-)
 create mode 100644 arch/riscv/include/asm/futex.h
 create mode 100644 arch/riscv/kernel/fpu.S
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-24 20:42 [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1 Palmer Dabbelt
  2018-10-24 20:42 ` Palmer Dabbelt
@ 2018-10-26  1:12 ` Linus Torvalds
  2018-10-26  1:12   ` Linus Torvalds
                     ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: Linus Torvalds @ 2018-10-26  1:12 UTC (permalink / raw)
  To: linux-riscv

On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> I'm pretty sure this is our largest patch set since the original kernel
> contribution, and it's certainly the one with the most contributors.
> While I don't have anything else I know I'm going to submit for the
> merge window, I would be somewhat surprised if I didn't screw anything
> up.

So I'm not entirely sure this is a screw-up, but it does have some
signs of being one:

>       lib: Add umoddi3 and udivmoddi4 of GCC library routines

We have *actively* tried to avoid needing umoddi3 and friends, and
have so far succceeded in doing that across many different
architectures, and many many years.

And when we _have_ added it, we've added it as architecture-specific
optimized routines when people really need it.

The reason to avoid a full 64-by-64 divide is that

 (a) it is really expensive

 (b) code that needs it is almost always actually wrong

Almost always, the 64-bit divide turns out to be entirely pointless,
and the code can be written as a (much cheaper) 64-by-32 divide
instead using the functions in <asm/div.h> instead.

Does RISC-V _really_ need that disgusting full 64-bit divide, or was
the addition of that simply a "we didn't know better, and didn't
realize just how expensive and wrong it is"?

I've pulled this, but I really _really_ hope that I will get a second
pull request that gets rid of this again, and fixes whatever RISC-V
code that triggered this to just do not do an insane full 64-bit
divide on a 32-bit architecture.

                Linus

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:12 ` Linus Torvalds
@ 2018-10-26  1:12   ` Linus Torvalds
  2018-10-26  1:35   ` Paul Walmsley
  2018-10-26 19:32   ` Palmer Dabbelt
  2 siblings, 0 replies; 14+ messages in thread
From: Linus Torvalds @ 2018-10-26  1:12 UTC (permalink / raw)
  To: palmer; +Cc: Greg KH, linux-riscv

On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> I'm pretty sure this is our largest patch set since the original kernel
> contribution, and it's certainly the one with the most contributors.
> While I don't have anything else I know I'm going to submit for the
> merge window, I would be somewhat surprised if I didn't screw anything
> up.

So I'm not entirely sure this is a screw-up, but it does have some
signs of being one:

>       lib: Add umoddi3 and udivmoddi4 of GCC library routines

We have *actively* tried to avoid needing umoddi3 and friends, and
have so far succceeded in doing that across many different
architectures, and many many years.

And when we _have_ added it, we've added it as architecture-specific
optimized routines when people really need it.

The reason to avoid a full 64-by-64 divide is that

 (a) it is really expensive

 (b) code that needs it is almost always actually wrong

Almost always, the 64-bit divide turns out to be entirely pointless,
and the code can be written as a (much cheaper) 64-by-32 divide
instead using the functions in <asm/div.h> instead.

Does RISC-V _really_ need that disgusting full 64-bit divide, or was
the addition of that simply a "we didn't know better, and didn't
realize just how expensive and wrong it is"?

I've pulled this, but I really _really_ hope that I will get a second
pull request that gets rid of this again, and fixes whatever RISC-V
code that triggered this to just do not do an insane full 64-bit
divide on a 32-bit architecture.

                Linus

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:12 ` Linus Torvalds
  2018-10-26  1:12   ` Linus Torvalds
@ 2018-10-26  1:35   ` Paul Walmsley
  2018-10-26  1:35     ` Paul Walmsley
                       ` (2 more replies)
  2018-10-26 19:32   ` Palmer Dabbelt
  2 siblings, 3 replies; 14+ messages in thread
From: Paul Walmsley @ 2018-10-26  1:35 UTC (permalink / raw)
  To: linux-riscv

+ Zong Li

Zong,

On 10/25/18 6:12 PM, Linus Torvalds wrote:
> On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>> I'm pretty sure this is our largest patch set since the original kernel
>> contribution, and it's certainly the one with the most contributors.
>> While I don't have anything else I know I'm going to submit for the
>> merge window, I would be somewhat surprised if I didn't screw anything
>> up.
> So I'm not entirely sure this is a screw-up, but it does have some
> signs of being one:
>
>>        lib: Add umoddi3 and udivmoddi4 of GCC library routines
> We have *actively* tried to avoid needing umoddi3 and friends, and
> have so far succceeded in doing that across many different
> architectures, and many many years.
>
> And when we _have_ added it, we've added it as architecture-specific
> optimized routines when people really need it.
>
> The reason to avoid a full 64-by-64 divide is that
>
>   (a) it is really expensive
>
>   (b) code that needs it is almost always actually wrong
>
> Almost always, the 64-bit divide turns out to be entirely pointless,
> and the code can be written as a (much cheaper) 64-by-32 divide
> instead using the functions in <asm/div.h> instead.
>
> Does RISC-V _really_ need that disgusting full 64-bit divide, or was
> the addition of that simply a "we didn't know better, and didn't
> realize just how expensive and wrong it is"?


I believe the request for those routines came from you:


https://lore.kernel.org/lkml/779b0b25cc96101a525402f38053db5e2f360d6f.1538535528.git.zongbox at gmail.com/


Do you in fact need a full 64-by-64 bit divide in your DMA driver, or 
can you

get away with using div_u64() et al.?


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/math64.h#n123


- Paul

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:35   ` Paul Walmsley
@ 2018-10-26  1:35     ` Paul Walmsley
  2018-10-26  1:51     ` Linus Torvalds
  2018-10-26 16:19     ` Zong Li
  2 siblings, 0 replies; 14+ messages in thread
From: Paul Walmsley @ 2018-10-26  1:35 UTC (permalink / raw)
  To: zongbox; +Cc: Greg KH, linux-riscv, palmer, Linus Torvalds

+ Zong Li

Zong,

On 10/25/18 6:12 PM, Linus Torvalds wrote:
> On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>> I'm pretty sure this is our largest patch set since the original kernel
>> contribution, and it's certainly the one with the most contributors.
>> While I don't have anything else I know I'm going to submit for the
>> merge window, I would be somewhat surprised if I didn't screw anything
>> up.
> So I'm not entirely sure this is a screw-up, but it does have some
> signs of being one:
>
>>        lib: Add umoddi3 and udivmoddi4 of GCC library routines
> We have *actively* tried to avoid needing umoddi3 and friends, and
> have so far succceeded in doing that across many different
> architectures, and many many years.
>
> And when we _have_ added it, we've added it as architecture-specific
> optimized routines when people really need it.
>
> The reason to avoid a full 64-by-64 divide is that
>
>   (a) it is really expensive
>
>   (b) code that needs it is almost always actually wrong
>
> Almost always, the 64-bit divide turns out to be entirely pointless,
> and the code can be written as a (much cheaper) 64-by-32 divide
> instead using the functions in <asm/div.h> instead.
>
> Does RISC-V _really_ need that disgusting full 64-bit divide, or was
> the addition of that simply a "we didn't know better, and didn't
> realize just how expensive and wrong it is"?


I believe the request for those routines came from you:


https://lore.kernel.org/lkml/779b0b25cc96101a525402f38053db5e2f360d6f.1538535528.git.zongbox@gmail.com/


Do you in fact need a full 64-by-64 bit divide in your DMA driver, or 
can you

get away with using div_u64() et al.?


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/math64.h#n123


- Paul


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:35   ` Paul Walmsley
  2018-10-26  1:35     ` Paul Walmsley
@ 2018-10-26  1:51     ` Linus Torvalds
  2018-10-26  1:51       ` Linus Torvalds
  2018-10-26 16:13       ` Zong Li
  2018-10-26 16:19     ` Zong Li
  2 siblings, 2 replies; 14+ messages in thread
From: Linus Torvalds @ 2018-10-26  1:51 UTC (permalink / raw)
  To: linux-riscv

On 10/25/18 6:12 PM, Linus Torvalds wrote:
>
> Almost always, the 64-bit divide turns out to be entirely pointless,
> and the code can be written as a (much cheaper) 64-by-32 divide
> instead using the functions in <asm/div.h> instead.

The other common situation for the kernel is that something was
written as "xyz / abc", when it turns out that abc is really just a
power-of-two.

So it's not necessarily always that the 64-bit divide can be
re-written as a 64-by-32 divide, sometimes it can be rewritten as
simply a shift. Which is even cheaper.

That's the reason I try to actively discourage full 64-by-64 divides.
We have had situations where people end up using a divide that can
take hundres of cycles, where alarmingly often it can be rewritten as
one that takes tens of cycles or even just _single_ cycles.

People don't sometimes appreciate just how expensive 64-by-64 divides
are when you don't have direct hardware support for them, and how
often there are much simpler and faster ways to avoid them.

                 Linus

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:51     ` Linus Torvalds
@ 2018-10-26  1:51       ` Linus Torvalds
  2018-10-26 16:13       ` Zong Li
  1 sibling, 0 replies; 14+ messages in thread
From: Linus Torvalds @ 2018-10-26  1:51 UTC (permalink / raw)
  To: paul.walmsley; +Cc: Greg KH, linux-riscv, palmer, zongbox

On 10/25/18 6:12 PM, Linus Torvalds wrote:
>
> Almost always, the 64-bit divide turns out to be entirely pointless,
> and the code can be written as a (much cheaper) 64-by-32 divide
> instead using the functions in <asm/div.h> instead.

The other common situation for the kernel is that something was
written as "xyz / abc", when it turns out that abc is really just a
power-of-two.

So it's not necessarily always that the 64-bit divide can be
re-written as a 64-by-32 divide, sometimes it can be rewritten as
simply a shift. Which is even cheaper.

That's the reason I try to actively discourage full 64-by-64 divides.
We have had situations where people end up using a divide that can
take hundres of cycles, where alarmingly often it can be rewritten as
one that takes tens of cycles or even just _single_ cycles.

People don't sometimes appreciate just how expensive 64-by-64 divides
are when you don't have direct hardware support for them, and how
often there are much simpler and faster ways to avoid them.

                 Linus

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:51     ` Linus Torvalds
  2018-10-26  1:51       ` Linus Torvalds
@ 2018-10-26 16:13       ` Zong Li
  2018-10-26 16:13         ` Zong Li
  1 sibling, 1 reply; 14+ messages in thread
From: Zong Li @ 2018-10-26 16:13 UTC (permalink / raw)
  To: linux-riscv

Linus Torvalds <torvalds@linux-foundation.org> ? 2018?10?26? ?? ??9:51???
>
> On 10/25/18 6:12 PM, Linus Torvalds wrote:
> >
> > Almost always, the 64-bit divide turns out to be entirely pointless,
> > and the code can be written as a (much cheaper) 64-by-32 divide
> > instead using the functions in <asm/div.h> instead.
>
> The other common situation for the kernel is that something was
> written as "xyz / abc", when it turns out that abc is really just a
> power-of-two.
>
> So it's not necessarily always that the 64-bit divide can be
> re-written as a 64-by-32 divide, sometimes it can be rewritten as
> simply a shift. Which is even cheaper.
>
> That's the reason I try to actively discourage full 64-by-64 divides.
> We have had situations where people end up using a divide that can
> take hundres of cycles, where alarmingly often it can be rewritten as
> one that takes tens of cycles or even just _single_ cycles.
>
> People don't sometimes appreciate just how expensive 64-by-64 divides
> are when you don't have direct hardware support for them, and how
> often there are much simpler and faster ways to avoid them.
>

Our driver guys implement the DMA driver which has a full 64-bit
divide in its initialization function. I had checked the code, it
could use the 64-by-32 divides in fact of the situation. I was not
conscious of the mistake and naively thought that umoddi3 is useful
for the other drivers which need the 64-by-64 divide. I would submit a
patch to get rid of these routines.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26 16:13       ` Zong Li
@ 2018-10-26 16:13         ` Zong Li
  0 siblings, 0 replies; 14+ messages in thread
From: Zong Li @ 2018-10-26 16:13 UTC (permalink / raw)
  To: torvalds; +Cc: gregkh, linux-riscv, Palmer Dabbelt, paul.walmsley

Linus Torvalds <torvalds@linux-foundation.org> 於 2018年10月26日 週五 上午9:51寫道:
>
> On 10/25/18 6:12 PM, Linus Torvalds wrote:
> >
> > Almost always, the 64-bit divide turns out to be entirely pointless,
> > and the code can be written as a (much cheaper) 64-by-32 divide
> > instead using the functions in <asm/div.h> instead.
>
> The other common situation for the kernel is that something was
> written as "xyz / abc", when it turns out that abc is really just a
> power-of-two.
>
> So it's not necessarily always that the 64-bit divide can be
> re-written as a 64-by-32 divide, sometimes it can be rewritten as
> simply a shift. Which is even cheaper.
>
> That's the reason I try to actively discourage full 64-by-64 divides.
> We have had situations where people end up using a divide that can
> take hundres of cycles, where alarmingly often it can be rewritten as
> one that takes tens of cycles or even just _single_ cycles.
>
> People don't sometimes appreciate just how expensive 64-by-64 divides
> are when you don't have direct hardware support for them, and how
> often there are much simpler and faster ways to avoid them.
>

Our driver guys implement the DMA driver which has a full 64-bit
divide in its initialization function. I had checked the code, it
could use the 64-by-32 divides in fact of the situation. I was not
conscious of the mistake and naively thought that umoddi3 is useful
for the other drivers which need the 64-by-64 divide. I would submit a
patch to get rid of these routines.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:35   ` Paul Walmsley
  2018-10-26  1:35     ` Paul Walmsley
  2018-10-26  1:51     ` Linus Torvalds
@ 2018-10-26 16:19     ` Zong Li
  2018-10-26 16:19       ` Zong Li
  2 siblings, 1 reply; 14+ messages in thread
From: Zong Li @ 2018-10-26 16:19 UTC (permalink / raw)
  To: linux-riscv

Paul Walmsley <paul.walmsley@sifive.com> ? 2018?10?26? ?? ??9:35???
>
> + Zong Li
>
> Zong,
>
> On 10/25/18 6:12 PM, Linus Torvalds wrote:
> > On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
> >> I'm pretty sure this is our largest patch set since the original kernel
> >> contribution, and it's certainly the one with the most contributors.
> >> While I don't have anything else I know I'm going to submit for the
> >> merge window, I would be somewhat surprised if I didn't screw anything
> >> up.
> > So I'm not entirely sure this is a screw-up, but it does have some
> > signs of being one:
> >
> >>        lib: Add umoddi3 and udivmoddi4 of GCC library routines
> > We have *actively* tried to avoid needing umoddi3 and friends, and
> > have so far succceeded in doing that across many different
> > architectures, and many many years.
> >
> > And when we _have_ added it, we've added it as architecture-specific
> > optimized routines when people really need it.
> >
> > The reason to avoid a full 64-by-64 divide is that
> >
> >   (a) it is really expensive
> >
> >   (b) code that needs it is almost always actually wrong
> >
> > Almost always, the 64-bit divide turns out to be entirely pointless,
> > and the code can be written as a (much cheaper) 64-by-32 divide
> > instead using the functions in <asm/div.h> instead.
> >
> > Does RISC-V _really_ need that disgusting full 64-bit divide, or was
> > the addition of that simply a "we didn't know better, and didn't
> > realize just how expensive and wrong it is"?
>
>
> I believe the request for those routines came from you:
>
>
> https://lore.kernel.org/lkml/779b0b25cc96101a525402f38053db5e2f360d6f.1538535528.git.zongbox at gmail.com/
>
>
> Do you in fact need a full 64-by-64 bit divide in your DMA driver, or
> can you
>
> get away with using div_u64() et al.?
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/math64.h#n123
>

Thanks for the information. The DMA driver could use the 64-by-32
divides in fact of the situation. I would submit a patch to drop this.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26 16:19     ` Zong Li
@ 2018-10-26 16:19       ` Zong Li
  0 siblings, 0 replies; 14+ messages in thread
From: Zong Li @ 2018-10-26 16:19 UTC (permalink / raw)
  To: paul.walmsley; +Cc: gregkh, linux-riscv, Palmer Dabbelt, torvalds

Paul Walmsley <paul.walmsley@sifive.com> 於 2018年10月26日 週五 上午9:35寫道:
>
> + Zong Li
>
> Zong,
>
> On 10/25/18 6:12 PM, Linus Torvalds wrote:
> > On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
> >> I'm pretty sure this is our largest patch set since the original kernel
> >> contribution, and it's certainly the one with the most contributors.
> >> While I don't have anything else I know I'm going to submit for the
> >> merge window, I would be somewhat surprised if I didn't screw anything
> >> up.
> > So I'm not entirely sure this is a screw-up, but it does have some
> > signs of being one:
> >
> >>        lib: Add umoddi3 and udivmoddi4 of GCC library routines
> > We have *actively* tried to avoid needing umoddi3 and friends, and
> > have so far succceeded in doing that across many different
> > architectures, and many many years.
> >
> > And when we _have_ added it, we've added it as architecture-specific
> > optimized routines when people really need it.
> >
> > The reason to avoid a full 64-by-64 divide is that
> >
> >   (a) it is really expensive
> >
> >   (b) code that needs it is almost always actually wrong
> >
> > Almost always, the 64-bit divide turns out to be entirely pointless,
> > and the code can be written as a (much cheaper) 64-by-32 divide
> > instead using the functions in <asm/div.h> instead.
> >
> > Does RISC-V _really_ need that disgusting full 64-bit divide, or was
> > the addition of that simply a "we didn't know better, and didn't
> > realize just how expensive and wrong it is"?
>
>
> I believe the request for those routines came from you:
>
>
> https://lore.kernel.org/lkml/779b0b25cc96101a525402f38053db5e2f360d6f.1538535528.git.zongbox@gmail.com/
>
>
> Do you in fact need a full 64-by-64 bit divide in your DMA driver, or
> can you
>
> get away with using div_u64() et al.?
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/math64.h#n123
>

Thanks for the information. The DMA driver could use the 64-by-32
divides in fact of the situation. I would submit a patch to drop this.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26  1:12 ` Linus Torvalds
  2018-10-26  1:12   ` Linus Torvalds
  2018-10-26  1:35   ` Paul Walmsley
@ 2018-10-26 19:32   ` Palmer Dabbelt
  2018-10-26 19:32     ` Palmer Dabbelt
  2 siblings, 1 reply; 14+ messages in thread
From: Palmer Dabbelt @ 2018-10-26 19:32 UTC (permalink / raw)
  To: linux-riscv

On Thu, 25 Oct 2018 18:12:46 PDT (-0700), Linus Torvalds wrote:
> On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>>
>> I'm pretty sure this is our largest patch set since the original kernel
>> contribution, and it's certainly the one with the most contributors.
>> While I don't have anything else I know I'm going to submit for the
>> merge window, I would be somewhat surprised if I didn't screw anything
>> up.
>
> So I'm not entirely sure this is a screw-up, but it does have some
> signs of being one:
>
>>       lib: Add umoddi3 and udivmoddi4 of GCC library routines
>
> We have *actively* tried to avoid needing umoddi3 and friends, and
> have so far succceeded in doing that across many different
> architectures, and many many years.
>
> And when we _have_ added it, we've added it as architecture-specific
> optimized routines when people really need it.
>
> The reason to avoid a full 64-by-64 divide is that
>
>  (a) it is really expensive
>
>  (b) code that needs it is almost always actually wrong
>
> Almost always, the 64-bit divide turns out to be entirely pointless,
> and the code can be written as a (much cheaper) 64-by-32 divide
> instead using the functions in <asm/div.h> instead.
>
> Does RISC-V _really_ need that disgusting full 64-bit divide, or was
> the addition of that simply a "we didn't know better, and didn't
> realize just how expensive and wrong it is"?
>
> I've pulled this, but I really _really_ hope that I will get a second
> pull request that gets rid of this again, and fixes whatever RISC-V
> code that triggered this to just do not do an insane full 64-bit
> divide on a 32-bit architecture.

Thanks.  We'll go figure out how to remove it.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1
  2018-10-26 19:32   ` Palmer Dabbelt
@ 2018-10-26 19:32     ` Palmer Dabbelt
  0 siblings, 0 replies; 14+ messages in thread
From: Palmer Dabbelt @ 2018-10-26 19:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Greg KH, linux-riscv

On Thu, 25 Oct 2018 18:12:46 PDT (-0700), Linus Torvalds wrote:
> On Wed, Oct 24, 2018 at 1:42 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>>
>> I'm pretty sure this is our largest patch set since the original kernel
>> contribution, and it's certainly the one with the most contributors.
>> While I don't have anything else I know I'm going to submit for the
>> merge window, I would be somewhat surprised if I didn't screw anything
>> up.
>
> So I'm not entirely sure this is a screw-up, but it does have some
> signs of being one:
>
>>       lib: Add umoddi3 and udivmoddi4 of GCC library routines
>
> We have *actively* tried to avoid needing umoddi3 and friends, and
> have so far succceeded in doing that across many different
> architectures, and many many years.
>
> And when we _have_ added it, we've added it as architecture-specific
> optimized routines when people really need it.
>
> The reason to avoid a full 64-by-64 divide is that
>
>  (a) it is really expensive
>
>  (b) code that needs it is almost always actually wrong
>
> Almost always, the 64-bit divide turns out to be entirely pointless,
> and the code can be written as a (much cheaper) 64-by-32 divide
> instead using the functions in <asm/div.h> instead.
>
> Does RISC-V _really_ need that disgusting full 64-bit divide, or was
> the addition of that simply a "we didn't know better, and didn't
> realize just how expensive and wrong it is"?
>
> I've pulled this, but I really _really_ hope that I will get a second
> pull request that gets rid of this again, and fixes whatever RISC-V
> code that triggered this to just do not do an insane full 64-bit
> divide on a 32-bit architecture.

Thanks.  We'll go figure out how to remove it.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2018-10-26 19:33 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-24 20:42 [GIT PULL] RISC-V Patches for the 4.20 Merge Window, Part 1 Palmer Dabbelt
2018-10-24 20:42 ` Palmer Dabbelt
2018-10-26  1:12 ` Linus Torvalds
2018-10-26  1:12   ` Linus Torvalds
2018-10-26  1:35   ` Paul Walmsley
2018-10-26  1:35     ` Paul Walmsley
2018-10-26  1:51     ` Linus Torvalds
2018-10-26  1:51       ` Linus Torvalds
2018-10-26 16:13       ` Zong Li
2018-10-26 16:13         ` Zong Li
2018-10-26 16:19     ` Zong Li
2018-10-26 16:19       ` Zong Li
2018-10-26 19:32   ` Palmer Dabbelt
2018-10-26 19:32     ` Palmer Dabbelt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).