@@ -620,9 +620,9 @@ Writeback.
620620The first can be used independently to the others. The VM can try to
621621either write dirty pages in order to clean them, or release clean pages
622622in order to reuse them. To do this it can call the ->writepage method
623- on dirty pages, and ->releasepage on clean pages with PagePrivate set.
624- Clean pages without PagePrivate and with no external references will be
625- released without notice being given to the address_space.
623+ on dirty pages, and ->release_folio on clean folios with the private
624+ flag set. Clean pages without PagePrivate and with no external references
625+ will be released without notice being given to the address_space.
626626
627627To achieve this functionality, pages need to be placed on an LRU with
628628lru_cache_add and mark_page_active needs to be called whenever the page
@@ -656,7 +656,7 @@ by memory-mapping the page. Data is written into the address space by
656656the application, and then written-back to storage typically in whole
657657pages, however the address_space has finer control of write sizes.
658658
659- The read process essentially only requires 'readpage '. The write
659+ The read process essentially only requires 'read_folio '. The write
660660process is more complicated and uses write_begin/write_end or
661661dirty_folio to write data into the address_space, and writepage and
662662writepages to writeback data to storage.
@@ -722,20 +722,20 @@ cache in your filesystem. The following members are defined:
722722
723723 struct address_space_operations {
724724 int (*writepage)(struct page *page, struct writeback_control *wbc);
725- int (*readpage )(struct file *, struct page *);
725+ int (*read_folio )(struct file *, struct folio *);
726726 int (*writepages)(struct address_space *, struct writeback_control *);
727727 bool (*dirty_folio)(struct address_space *, struct folio *);
728728 void (*readahead)(struct readahead_control *);
729729 int (*write_begin)(struct file *, struct address_space *mapping,
730- loff_t pos, unsigned len, unsigned flags,
730+ loff_t pos, unsigned len,
731731 struct page **pagep, void **fsdata);
732732 int (*write_end)(struct file *, struct address_space *mapping,
733733 loff_t pos, unsigned len, unsigned copied,
734734 struct page *page, void *fsdata);
735735 sector_t (*bmap)(struct address_space *, sector_t);
736736 void (*invalidate_folio) (struct folio *, size_t start, size_t len);
737- int (*releasepage) (struct page *, int );
738- void (*freepage )(struct page *);
737+ bool (*release_folio) (struct folio *, gfp_t );
738+ void (*free_folio )(struct folio *);
739739 ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter);
740740 /* isolate a page for migration */
741741 bool (*isolate_page) (struct page *, isolate_mode_t);
@@ -747,7 +747,7 @@ cache in your filesystem. The following members are defined:
747747
748748 bool (*is_partially_uptodate) (struct folio *, size_t from,
749749 size_t count);
750- void (*is_dirty_writeback) (struct page *, bool *, bool *);
750+ void (*is_dirty_writeback)(struct folio *, bool *, bool *);
751751 int (*error_remove_page) (struct mapping *mapping, struct page *page);
752752 int (*swap_activate)(struct file *);
753753 int (*swap_deactivate)(struct file *);
@@ -772,14 +772,14 @@ cache in your filesystem. The following members are defined:
772772
773773 See the file "Locking" for more details.
774774
775- ``readpage ``
776- called by the VM to read a page from backing store. The page
777- will be Locked when readpage is called, and should be unlocked
778- and marked uptodate once the read completes. If ->readpage
779- discovers that it needs to unlock the page for some reason , it
780- can do so, and then return AOP_TRUNCATED_PAGE. In this case,
781- the page will be relocated , relocked and if that all succeeds,
782- ->readpage will be called again.
775+ ``read_folio ``
776+ called by the VM to read a folio from backing store. The folio
777+ will be locked when read_folio is called, and should be unlocked
778+ and marked uptodate once the read completes. If ->read_folio
779+ discovers that it cannot perform the I/O at this time , it can
780+ unlock the folio and return AOP_TRUNCATED_PAGE. In this case,
781+ the folio will be looked up again , relocked and if that all succeeds,
782+ ->read_folio will be called again.
783783
784784``writepages ``
785785 called by the VM to write out pages associated with the
@@ -832,9 +832,6 @@ cache in your filesystem. The following members are defined:
832832 passed to write_begin is greater than the number of bytes copied
833833 into the page).
834834
835- flags is a field for AOP_FLAG_xxx flags, described in
836- include/linux/fs.h.
837-
838835 A void * may be returned in fsdata, which then gets passed into
839836 write_end.
840837
@@ -867,36 +864,35 @@ cache in your filesystem. The following members are defined:
867864 address space. This generally corresponds to either a
868865 truncation, punch hole or a complete invalidation of the address
869866 space (in the latter case 'offset' will always be 0 and 'length'
870- will be folio_size()). Any private data associated with the page
867+ will be folio_size()). Any private data associated with the folio
871868 should be updated to reflect this truncation. If offset is 0
872869 and length is folio_size(), then the private data should be
873- released, because the page must be able to be completely
874- discarded. This may be done by calling the ->releasepage
870+ released, because the folio must be able to be completely
871+ discarded. This may be done by calling the ->release_folio
875872 function, but in this case the release MUST succeed.
876873
877- ``releasepage ``
878- releasepage is called on PagePrivate pages to indicate that the
879- page should be freed if possible. ->releasepage should remove
880- any private data from the page and clear the PagePrivate flag.
881- If releasepage() fails for some reason, it must indicate failure
882- with a 0 return value. releasepage() is used in two distinct
883- though related cases. The first is when the VM finds a clean
884- page with no active users and wants to make it a free page. If
885- ->releasepage succeeds, the page will be removed from the
886- address_space and become free.
874+ ``release_folio ``
875+ release_folio is called on folios with private data to tell the
876+ filesystem that the folio is about to be freed. ->release_folio
877+ should remove any private data from the folio and clear the
878+ private flag. If release_folio() fails, it should return false.
879+ release_folio() is used in two distinct though related cases.
880+ The first is when the VM wants to free a clean folio with no
881+ active users. If ->release_folio succeeds, the folio will be
882+ removed from the address_space and be freed.
887883
888884 The second case is when a request has been made to invalidate
889- some or all pages in an address_space. This can happen through
890- the fadvise(POSIX_FADV_DONTNEED) system call or by the
891- filesystem explicitly requesting it as nfs and 9fs do (when they
885+ some or all folios in an address_space. This can happen
886+ through the fadvise(POSIX_FADV_DONTNEED) system call or by the
887+ filesystem explicitly requesting it as nfs and 9p do (when they
892888 believe the cache may be out of date with storage) by calling
893889 invalidate_inode_pages2(). If the filesystem makes such a call,
894- and needs to be certain that all pages are invalidated, then its
895- releasepage will need to ensure this. Possibly it can clear the
896- PageUptodate bit if it cannot free private data yet.
890+ and needs to be certain that all folios are invalidated, then
891+ its release_folio will need to ensure this. Possibly it can
892+ clear the uptodate flag if it cannot free private data yet.
897893
898- ``freepage ``
899- freepage is called once the page is no longer visible in the
894+ ``free_folio ``
895+ free_folio is called once the folio is no longer visible in the
900896 page cache in order to allow the cleanup of any private data.
901897 Since it may be called by the memory reclaimer, it should not
902898 assume that the original address_space mapping still exists, and
@@ -935,14 +931,14 @@ cache in your filesystem. The following members are defined:
935931 without needing I/O to bring the whole page up to date.
936932
937933``is_dirty_writeback ``
938- Called by the VM when attempting to reclaim a page . The VM uses
934+ Called by the VM when attempting to reclaim a folio . The VM uses
939935 dirty and writeback information to determine if it needs to
940936 stall to allow flushers a chance to complete some IO.
941- Ordinarily it can use PageDirty and PageWriteback but some
942- filesystems have more complex state (unstable pages in NFS
937+ Ordinarily it can use folio_test_dirty and folio_test_writeback but
938+ some filesystems have more complex state (unstable folios in NFS
943939 prevent reclaim) or do not set those flags due to locking
944940 problems. This callback allows a filesystem to indicate to the
945- VM if a page should be treated as dirty or writeback for the
941+ VM if a folio should be treated as dirty or writeback for the
946942 purposes of stalling.
947943
948944``error_remove_page ``
0 commit comments