lkml.org 
[lkml]   [2018]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
    Date
    From: Rahul Lakkireddy
    > Sent: 19 March 2018 14:21
    >
    > This series of patches add support for 256-bit IO read and write.
    > The APIs are readqq and writeqq (quad quadword - 4 x 64), that read
    > and write 256-bits at a time from IO, respectively.

    Why not use the AVX2 registers to get 512bit accesses.

    > Patch 1 adds u256 type and adds necessary non-atomic accessors. Also
    > adds byteorder conversion APIs.
    >
    > Patch 2 adds 256-bit read and write to x86 via VMOVDQU AVX CPU
    > instructions.
    >
    > Patch 3 updates cxgb4 driver to use the readqq API to speed up
    > reading on-chip memory 256-bits at a time.

    Calling kernel_fpu_begin() is likely to be slow.
    I doubt you want to do it every time around a loop of accesses.

    In principle it ought to be possible to get access to one or two
    (eg) AVX registers by saving them to stack and telling the fpu
    save code where you've put them.
    Then the IPI fp save code could then copy the saved values over
    the current values if asked to save the fp state for a process.
    This should be reasonable cheap - especially if there isn't an
    fp save IPI.

    OTOH, for x86, if the code always runs in process context (eg from a
    system call) then, since the ABI defines them all as caller-saved
    the AVX(2) registers, it is only necessary to ensure that the current
    FPU registers belong to the current process once.
    The registers can be set to zero by an 'invalidate' instruction on
    system call entry (hope this is done) and after use.

    David

    \
     
     \ /
      Last update: 2018-03-19 15:52    [W:4.097 / U:1.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site