Hi Finn,
Am 13.10.2018 um 17:09 schrieb Finn Thain:
On Sat, 13 Oct 2018, Michael Schmitz wrote:
Hi Finn,
Am 13.10.2018 um 13:51 schrieb Finn Thain:
Avoid function calls in the inner PIO loops. On a Centris 660av this
improves throughput for sequential read transfers by about 40% and
sequenti
On Sat, 13 Oct 2018, Michael Schmitz wrote:
> Hi Finn,
>
> Am 13.10.2018 um 13:51 schrieb Finn Thain:
> > Avoid function calls in the inner PIO loops. On a Centris 660av this
> > improves throughput for sequential read transfers by about 40% and
> > sequential write by about 10%.
> >
> > Unfortu
Hi Finn,
Am 13.10.2018 um 13:51 schrieb Finn Thain:
Avoid function calls in the inner PIO loops. On a Centris 660av this
improves throughput for sequential read transfers by about 40% and
sequential write by about 10%.
Unfortunately it is not possible to have method calls like esp_write8()
plac
Hi Geert,
Am 12.10.2018 um 21:59 schrieb Geert Uytterhoeven:
Changes from v4:
Andreas Schwab:
- correct cast to sector_t in sector address calculations
Which you only did for the first case...
--- a/block/partitions/amiga.c
+++ b/block/partitions/amiga.c
@@ -100,14 +101,14 @@ int amiga_
On Fri, Oct 12, 2018 at 7:10 PM, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 06:54:33PM -0700, Daniel Colascione wrote:
>> I wonder whether it makes sense to expose to userspace somehow whether
>> mremap is "fast" for a particular architecture. If a feature relies on
>> fast mremap, it might b
Hi Geert,
Am 12.10.2018 um 21:54 schrieb Geert Uytterhoeven:
Thanks for being persistent!
BTW, there's another possible overflow in "blk *= blksize", but that one
is very unlikely to happen, as most (all?) partitioners store partition
blocks close to the beginning of the disk.
Thanks - we ca
On Fri, Oct 12, 2018 at 06:54:33PM -0700, Daniel Colascione wrote:
> I wonder whether it makes sense to expose to userspace somehow whether
> mremap is "fast" for a particular architecture. If a feature relies on
> fast mremap, it might be better for some userland component to disable
> that featur
I wonder whether it makes sense to expose to userspace somehow whether
mremap is "fast" for a particular architecture. If a feature relies on
fast mremap, it might be better for some userland component to disable
that feature entirely rather than blindly use mremap and end up
performing very poorly
On Fri, Oct 12, 2018 at 06:39:45PM -0700, Daniel Colascione wrote:
> Not 32-bit ARM?
Well, I didn't want to enable every possible architecture we could in a
single go. Certainly arm32 can be a follow on enablement as can be other
architectures. The point of this series is to upstream this feature
Not 32-bit ARM?
On Fri, Oct 12, 2018 at 6:35 PM, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
>> From: Joel Fernandes
> [...]
>> > Also, do we not flush the caches from any path when we munmap
>> > address space? We do call do_munmap on the old mapping f
On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space? We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
>
> Sparc makes sure that shared ma
This series has fixes and cleanup for mac_esp, zorro_esp and the
core esp_scsi driver.
The improvements include elimination of duplicated code temporarily
introduced for zorro_esp.
Michael, would you please regression test this series on elgar,
if convenient? So far, only mac_esp has been tested
If a target disconnects during a PIO data transfer the command may
fail when the target reconnects:
scsi host1: DMA length is zero!
scsi host1: cur adr[0438] len[]
The scsi bus is then reset. This happens because the residual reached
zero before the transfer was completed.
The usual
Avoid function calls in the inner PIO loops. On a Centris 660av this
improves throughput for sequential read transfers by about 40% and
sequential write by about 10%.
Unfortunately it is not possible to have method calls like esp_write8()
placed inline so this is always going to be slow (even with
The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so
the chip's Transfer Counter register is only 16 bits wide (not 24).
A larger transfer cannot work and will theoretically result in a failed
command and a "DMA length is zero" error.
Fixes: 3109e5ae0311
Signed-off-by: Finn Thain
As a temporary measure, the code to implement PIO transfers was
duplicated in zorro_esp and mac_esp. Now that this code has stabilized,
move it into the core driver to eliminate the duplication.
This replaces the inline assembler with more portable writesb() calls.
Optimizing the m68k writesb() im
The concept of a 'slow command' as it appears in esp_scsi is confusing
because it could refer to an ESP command or a SCSI command. It turns out
that it refers to a particular ESP select command which the driver also
tracks as 'ESP_SELECT_MSGOUT'. For readability, it is better to use the
terminology
A SCSI device is not granted disconnect privilege by an esp_scsi host
unless that device has its simple_tags flag set. However, a device may
support disconnect/reselect and not support command queueing. Allow
these devices to disconnect and improve bus utilization.
Tested-by: Stan Johnson
Signed-
Unroll the raw_outsb() loop using the optimized assembler code from
raw_outsw(). That code is copied and pasted, with movew changed to moveb.
This improves the performance of sequential write transfers using mac_esp
in PIO mode by 5% or 10%. (The DMA controller on the 840av/660av models is
still u
From: Joel Fernandes
Date: Fri, 12 Oct 2018 05:50:46 -0700
> If its an issue, then how do transparent huge pages work on Sparc? I don't
> see the huge page code (move_huge_pages) during mremap doing anything special
> for Sparc architecture when moving PMDs..
This is because all huge pages are
From: "Kirill A. Shutemov"
Date: Fri, 12 Oct 2018 14:30:56 +0300
> I looked into the code more and noticed move_pte() helper called from
> move_ptes(). It changes PTE entry to suite new address.
>
> It is only defined in non-trivial way on Sparc. I don't know much about
> Sparc and it's hard for
Hi Michael,
On Fri, Oct 12, 2018 at 2:27 AM Michael Schmitz wrote:
> The Amiga partition parser module uses signed int for partition sector
> address and count, which will overflow for disks larger than 1 TB.
>
> Use sector_t as type for sector address and size to allow using disks
> up to 2 TB w
Hi Michael,
On Fri, Oct 12, 2018 at 2:27 AM Michael Schmitz wrote:
> The Amiga partition parser module uses signed int for partition sector
> address and count, which will overflow for disks larger than 1 TB.
>
> Use u64 as type for sector address and size to allow using disks up to
> 2 TB withou
On 10/12/18 10:17 AM, Martin Steigerwald wrote:
> Just as a note for all the AmigaOS users out there: Hyperion
> Entertainment released AmigaOS 3.1.4 for various Amiga models. This
> should fix all (known) issues with large disks for good directly in the
> Kickstart ROM instead of via SetPatch upda
Michael Schmitz - 12.10.18, 02:26:
> yet another new version of the Amiga RDB partition table patch.
> I've split off the part fixing the incorrect use of signed int
> for partition start address and size as separate patch. This change
> should be incontroversial (I hope). It does fix the bug that
25 matches
Mail list logo
