Re: Should implementations of ->direct_access be allowed to sleep?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux