lkml.org 
[lkml]   [2015]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v4 1/5] fs: kiocb: introduce IOCB_DONT_DIRTY_PAGE flag for direct IO
From
On Tue, Jun 9, 2015 at 2:29 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Jun 06, 2015 at 08:42:33AM +0800, Ming Lei wrote:
>> Both ITER_KVEC and ITER_BVEC doesn't mean the pages are kernel
>> page, for example of loop and swap. That is why this patch is more flexiable,
>> and won't cause regression since the users may have different dirtying
>> rules as you mentioned last time.
>>
>> http://marc.info/?t=143093223200001&r=1&w=2
>
> Again, we never dirty pages for the caller when doing general purpose
> kernel I/O. For loop we either don't need it (totally in-kernel block
> I/O) or the caller takes care of it (direct I/O on the loop device).
>
> The swap code currently only uses ->direct_IO and thus isn't affected
> by this flag. If we use it for write the low-level I/O code should not
> dirty the page either.
>
> So to repeat myself: for the current state of affairs adding a flag
> that every sensible user has to set is a horrible interface. If for

There shouldn't be lots of such uses, and the flag still has the
document benifit, that means the caller should think and check
the current dirtying usage.

> some unforseen reason we'll need the flag later on it should have
> reverse polarity, and only be added when needed.

OK, I will remove the flag in v5 since loop dio is the 1st read
->direct_IO via ITER_KVEC/ITER_BVEC inside kernel.

But I am wondering it is good to decide dirtying by
ITER_KVEC and ITER_BVEC, and dirtying pages should better
be checked case by case, at least for loop, the usage is a bit
special(fs over loop is taking care of that)


Thanks,
Ming


\
 
 \ /
  Last update: 2015-06-09 12:21    [W:0.063 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site