On 27 Apr 2000, Trond Myklebust wrote:
>In essence I meant it to be a hint from the VFS to the underlying
Minor note: it's not an hint from VFS but from the VM.
>filesystem that it wants to change the state of the page in some
>fashion that is affected by/will affect asynchronous operations.
Every I/O operation is asynchronous until you do wait_on_page/buffer().
>
>Currently, that means:
>
> 1) I want to grab the page lock. Please complete the pagein or
The page lock is indipendent of the buffer lock so you don't have to
bother on the state of the page, just grab it and once you have it you can
play with the page. For data-fs writes the page lock is dropped once the
buffer gets marked dirty. Only the brw_page interface keeps the page lock
so you can wait_on_page() also on page-writes.
> whatever other asynchronous operations that are holding us up.
Why do you really want to complete the I/O? Answer: because of point (2)
you write below.
>
> 2) I want to reclaim the page. Please put out any pending
> asynchronous writes on this page as quickly as you can.
That's why flushpage exits. Point (2) is just addressed or we would have
corruption going on.
>The idea with the latter is ultimately to provide a unified interface
>for memory reclaiming. In particular I want to allow a cleanup of
we just have it, it's flushpage.
>shrink_mmap() to make it work on generic filesystems which support
>asynchronous operations.
shrink_mmap just works for all filesystems. I don't see what you mean.
>I thought that the 2 cases could be combined into 1 callback and that
>the filesystem should be able to decide from context what exactly
>needs to be done. Perhaps this assumption was wrong, and we should
>implement
>
> 1) sync_page()
> 2) reclaim_page()
>
>as 2 different callbacks?
I don't see your point sorry.
Could you tell exactly what is going wrong right now or where we are not
fast enough?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST