[lkml]   [2015]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Should implementations of ->direct_access be allowed to sleep?
    On 03/26/2015 09:32 PM, Dave Chinner wrote:
    >> I'm leaning towards the latter. But I'm not sure what GFP flags to
    >> recommend that brd use ... GFP_NOWAIT | __GFP_ZERO, perhaps?
    > What, so we get random IO failures under memory pressure?
    > I really think we should allow .direct_access to sleep. It means we
    > can use existing drivers and it also allows future implementations
    > that might require, say, RDMA to be performed to update a page
    > before access is granted. i.e. .direct_access is the first hook into
    > the persistent device at page fault time....

    I agree with Dave. Last I tried (couple years ago) doing any
    allocation GFP_NOWAIT on FS IO paths fails really badly in all kind
    of surprising ways. The Kernel is built in to that allocation pressure.

    I think that ->direct_access should not be any different then
    any other block-device access, ie allow to sleep.

    With brd a user can make sure not to sleep if he pre-allocates
    ie call ->direct_access at least once on a given offset-length.
    But I would not like to even do that guaranty. ->direct_access
    should be allowed to sleep.
    Well written code has many ways to allow sleep yet be very low
    latency. (So I do not see what we are missing)

    > Cheers,
    > Dave.


     \ /
      Last update: 2015-03-29 10:41    [W:6.951 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site