Hi J�r�me, On Tue, Jan 21, 2020 at 06:32:22PM -0800, jglisse@xxxxxxxxxx wrote: > From: J�r�me Glisse <jglisse@xxxxxxxxxx> > > <snip> > > To avoid any regression risks the page->mapping field is left intact as > today for non write protect pages. This means that if you do not use the > page write protection mechanism then it can not regress. This is achieve > by using an helper function that take the mapping from the context > (current function parameter, see above on how function are updated) and > the struct page. If the page is not write protected then it uses the > mapping from the struct page (just like today). The only difference > between before and after the patchset is that all fs functions that do > need the mapping for a page now also do get it as a parameter but only > use the parameter mapping pointer if the page is write protected. > > Note also that i do not believe that once confidence is high that we > always passdown the correct mapping down each callstack, it does not > mean we will be able to get rid of the struct page mapping field. This feature is awesome and I might have some premature words here... In short, are you suggesting completely getting rid of all way to access mapping directly from struct page (other than by page->private or something else like calling trace)? I'm not sure if all cases can be handled without page->mapping easily (or handled effectively) since mapping field could also be used to indicate/judge truncated pages or some other filesystem specific states (okay, I think there could be some replacement, but it seems a huge project...) Currently, page->private is a per-page user-defined field, yet I don't think it could always be used as a pointer pointing to some structure. It can be simply used to store some unsigned long values for some kinds of filesystem pages as well... It might some ineffective to convert such above usage to individual per-page structure pointers --- from cacheline or extra memory overhead view... So I think at least there could be some another way to get its content source (inode or sub-inode granularity, a reverse way) effectively... by some field in struct page directly or indirectly... I agree that the usage of page->mapping field is complicated for now. I'm looking forward some unique way to mark the page type for a filesystem to use (inode or fs internal special pages) or even extend to analymous pages [1]. However, it seems a huge project to keep from some regression... I'm interested in related stuffs, some conclusion and I saw the article of LSF/MM 2018 although my English isn't good... If something wrong, please kindly point out... [1] https://lore.kernel.org/r/20191030172234.GA7018@hsiangkao-HP-ZHAN-66-Pro-G1 Thanks, Gao Xiang
