| Message ID | 20221229225100.22141-1-fmdefrancesco@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | fs/ufs: Replace kmap() with kmap_local_page | expand |
On giovedì 29 dicembre 2022 23:50:56 CEST Fabio M. De Francesco wrote: > kmap() is being deprecated in favor of kmap_local_page(). > > There are two main problems with kmap(): (1) It comes with an overhead as > the mapping space is restricted and protected by a global lock for > synchronization and (2) it also requires global TLB invalidation when the > kmap’s pool wraps and it might block when the mapping space is fully > utilized until a slot becomes available. > > With kmap_local_page() the mappings are per thread, CPU local, can take > page faults, and can be called from any context (including interrupts). > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > the tasks can be preempted and, when they are scheduled to run again, the > kernel virtual addresses are restored and still valid. > > Since its use in fs/ufs is safe everywhere, it should be preferred. > > Therefore, replace kmap() with kmap_local_page() in fs/ufs. kunmap_local() > requires the mapping address, so return that address from ufs_get_page() > to be used in ufs_put_page(). Hi Al, I see that this series is here since Dec 29, 2022. Is there anything that prevents its merging? Can you please its four patches in your tree? Thanks, Fabio > > This series could have not been ever made because nothing prevented the > previous patch from working properly but Al Viro made a long series of > very appreciated comments about how many unnecessary and redundant lines > of code I could have removed. He could see things I was entirely unable > to notice. Furthermore, he also provided solutions and details about how > I could decompose a single patch into a small series of three > independent units.[1][2][3] > > I want to thank him so much for the patience, kindness and the time he > decided to spend to provide those analysis and write three messages full > of interesting insights.[1][2][3] > > Cc: Al Viro <viro@zeniv.linux.org.uk> > Cc: Ira Weiny <ira.weiny@intel.com> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> > > Changes from v1: > 1/3: No changes. > 2/3: Restore the return of "err" that was mistakenly deleted > together with the removal of the "out" label in > ufs_add_link(). Thanks to Al Viro.[4] > Return the address of the kmap()'ed page instead of a > pointer to a pointer to the mapped page; a page_address() > had been overlooked in ufs_get_page(). Thanks to Al > Viro.[5] > 3/3: Return the kernel virtual address got from the call to > kmap_local_page() after conversion from kmap(). Again > thanks to Al Viro.[6] > > Changes from v2: > 1/3: No changes. > 2/3: Rework ufs_get_page() because the previous version had two > errors: (1) It could return an invalid pages with the out > argument "page" and (2) it could return "page_address(page)" > also in cases where read_mapping_page() returned an error > and the page is never kmap()'ed. Thanks to Al Viro.[7] > 3/3: Rework ufs_get_page() after conversion to > kmap_local_page(), in accordance to the last changes in 2/3. > > Changes from v3: > 1/3: No changes. > 2/3: No changes. > 3/3: Replace kunmap() with kunmap_local(). > > Changes from v4: > 1/4: It was 1/3. > 2/4: Move the declaration of a page into an inner loop. Add Ira > Weiny's "Reviewed-by" tag (thanks!). > 3/4: Add this patch to use ufs_put_page() to replace three kunmap() > and put_page() in namei.c. Thanks to Ira Weiny who noticed that > I had overlooked their presence. > 4/4: Remove an unnecessary masking that is already carried out by > kunmap_local() via kunmap_local_indexed(). Add a comment to > clarify that a ufs_dir_entry passed to ufs_delete_entry() > points in the same page we need the address of. Suggested by > Ira Weiny. > > [1] https://lore.kernel.org/lkml/Y4E++JERgUMoqfjG@ZenIV/#t > [2] https://lore.kernel.org/lkml/Y4FG0O7VWTTng5yh@ZenIV/#t > [3] https://lore.kernel.org/lkml/Y4ONIFJatIGsVNpf@ZenIV/#t > [4] https://lore.kernel.org/lkml/Y5Zc0qZ3+zsI74OZ@ZenIV/#t > [5] https://lore.kernel.org/lkml/Y5ZZy23FFAnQDR3C@ZenIV/#t > [6] https://lore.kernel.org/lkml/Y5ZcMPzPG9h6C9eh@ZenIV/#t > [7] https://lore.kernel.org/lkml/Y5glgpD7fFifC4Fi@ZenIV/#t > > The cover letter of the v1 series is at > https://lore.kernel.org/lkml/20221211213111.30085-1-fmdefrancesco@gmail.com/ > The cover letter of the v2 series is at > https://lore.kernel.org/lkml/20221212231906.19424-1-fmdefrancesco@gmail.com/ > The cover letter of the v3 series is at > https://lore.kernel.org/lkml/20221217184749.968-1-fmdefrancesco@gmail.com/ > The cover letter of the v4 series is at > https://lore.kernel.org/lkml/20221221172802.18743-1-fmdefrancesco@gmail.com/ > > Fabio M. De Francesco (4): > fs/ufs: Use the offset_in_page() helper > fs/ufs: Change the signature of ufs_get_page() > fs/ufs: Use ufs_put_page() in ufs_rename() > fs/ufs: Replace kmap() with kmap_local_page() > > fs/ufs/dir.c | 131 +++++++++++++++++++++++++++---------------------- > fs/ufs/namei.c | 11 ++--- > fs/ufs/ufs.h | 1 + > 3 files changed, 78 insertions(+), 65 deletions(-) > > -- > 2.39.0
On Mon, Mar 27, 2023 at 12:13:08PM +0200, Fabio M. De Francesco wrote: > On giovedì 29 dicembre 2022 23:50:56 CEST Fabio M. De Francesco wrote: > > kmap() is being deprecated in favor of kmap_local_page(). > > > > There are two main problems with kmap(): (1) It comes with an overhead as > > the mapping space is restricted and protected by a global lock for > > synchronization and (2) it also requires global TLB invalidation when the > > kmap’s pool wraps and it might block when the mapping space is fully > > utilized until a slot becomes available. > > > > With kmap_local_page() the mappings are per thread, CPU local, can take > > page faults, and can be called from any context (including interrupts). > > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > > the tasks can be preempted and, when they are scheduled to run again, the > > kernel virtual addresses are restored and still valid. > > > > Since its use in fs/ufs is safe everywhere, it should be preferred. > > > > Therefore, replace kmap() with kmap_local_page() in fs/ufs. kunmap_local() > > requires the mapping address, so return that address from ufs_get_page() > > to be used in ufs_put_page(). > > Hi Al, > > I see that this series is here since Dec 29, 2022. > Is there anything that prevents its merging? > Can you please its four patches in your tree? I'm pretty sure UFS directories should simply be allocated from lowmem. There's really no reason to put them in highmem these days.
On lunedì 27 marzo 2023 15:23:41 CEST Matthew Wilcox wrote: > On Mon, Mar 27, 2023 at 12:13:08PM +0200, Fabio M. De Francesco wrote: > > On giovedì 29 dicembre 2022 23:50:56 CEST Fabio M. De Francesco wrote: > > > kmap() is being deprecated in favor of kmap_local_page(). > > > > > > There are two main problems with kmap(): (1) It comes with an overhead as > > > the mapping space is restricted and protected by a global lock for > > > synchronization and (2) it also requires global TLB invalidation when the > > > kmap’s pool wraps and it might block when the mapping space is fully > > > utilized until a slot becomes available. > > > > > > With kmap_local_page() the mappings are per thread, CPU local, can take > > > page faults, and can be called from any context (including interrupts). > > > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > > > the tasks can be preempted and, when they are scheduled to run again, the > > > kernel virtual addresses are restored and still valid. > > > > > > Since its use in fs/ufs is safe everywhere, it should be preferred. > > > > > > Therefore, replace kmap() with kmap_local_page() in fs/ufs. kunmap_local() > > > requires the mapping address, so return that address from ufs_get_page() > > > to be used in ufs_put_page(). > > > > Hi Al, > > > > I see that this series is here since Dec 29, 2022. > > Is there anything that prevents its merging? > > Can you please its four patches in your tree? > > I'm pretty sure UFS directories should simply be allocated from lowmem. > There's really no reason to put them in highmem these days. Matthew, It's been a few days since you wrote but I still haven't done anything or replied. For now, I just want you to know that it's not my intention to ignore your comment. The only reasons I hesitate to follow your directions are that I built this series based on specific suggestions from Al. While I understand and, for sure, heed what you said, I also think I should wait for Al to chime in with what he thinks about all this before taking a different route for removing kmap() from fs/ufs. Thanks for looking at this series. Fabio
kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid. Since its use in fs/ufs is safe everywhere, it should be preferred. Therefore, replace kmap() with kmap_local_page() in fs/ufs. kunmap_local() requires the mapping address, so return that address from ufs_get_page() to be used in ufs_put_page(). This series could have not been ever made because nothing prevented the previous patch from working properly but Al Viro made a long series of very appreciated comments about how many unnecessary and redundant lines of code I could have removed. He could see things I was entirely unable to notice. Furthermore, he also provided solutions and details about how I could decompose a single patch into a small series of three independent units.[1][2][3] I want to thank him so much for the patience, kindness and the time he decided to spend to provide those analysis and write three messages full of interesting insights.[1][2][3] Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Changes from v1: 1/3: No changes. 2/3: Restore the return of "err" that was mistakenly deleted together with the removal of the "out" label in ufs_add_link(). Thanks to Al Viro.[4] Return the address of the kmap()'ed page instead of a pointer to a pointer to the mapped page; a page_address() had been overlooked in ufs_get_page(). Thanks to Al Viro.[5] 3/3: Return the kernel virtual address got from the call to kmap_local_page() after conversion from kmap(). Again thanks to Al Viro.[6] Changes from v2: 1/3: No changes. 2/3: Rework ufs_get_page() because the previous version had two errors: (1) It could return an invalid pages with the out argument "page" and (2) it could return "page_address(page)" also in cases where read_mapping_page() returned an error and the page is never kmap()'ed. Thanks to Al Viro.[7] 3/3: Rework ufs_get_page() after conversion to kmap_local_page(), in accordance to the last changes in 2/3. Changes from v3: 1/3: No changes. 2/3: No changes. 3/3: Replace kunmap() with kunmap_local(). Changes from v4: 1/4: It was 1/3. 2/4: Move the declaration of a page into an inner loop. Add Ira Weiny's "Reviewed-by" tag (thanks!). 3/4: Add this patch to use ufs_put_page() to replace three kunmap() and put_page() in namei.c. Thanks to Ira Weiny who noticed that I had overlooked their presence. 4/4: Remove an unnecessary masking that is already carried out by kunmap_local() via kunmap_local_indexed(). Add a comment to clarify that a ufs_dir_entry passed to ufs_delete_entry() points in the same page we need the address of. Suggested by Ira Weiny. [1] https://lore.kernel.org/lkml/Y4E++JERgUMoqfjG@ZenIV/#t [2] https://lore.kernel.org/lkml/Y4FG0O7VWTTng5yh@ZenIV/#t [3] https://lore.kernel.org/lkml/Y4ONIFJatIGsVNpf@ZenIV/#t [4] https://lore.kernel.org/lkml/Y5Zc0qZ3+zsI74OZ@ZenIV/#t [5] https://lore.kernel.org/lkml/Y5ZZy23FFAnQDR3C@ZenIV/#t [6] https://lore.kernel.org/lkml/Y5ZcMPzPG9h6C9eh@ZenIV/#t [7] https://lore.kernel.org/lkml/Y5glgpD7fFifC4Fi@ZenIV/#t The cover letter of the v1 series is at https://lore.kernel.org/lkml/20221211213111.30085-1-fmdefrancesco@gmail.com/ The cover letter of the v2 series is at https://lore.kernel.org/lkml/20221212231906.19424-1-fmdefrancesco@gmail.com/ The cover letter of the v3 series is at https://lore.kernel.org/lkml/20221217184749.968-1-fmdefrancesco@gmail.com/ The cover letter of the v4 series is at https://lore.kernel.org/lkml/20221221172802.18743-1-fmdefrancesco@gmail.com/ Fabio M. De Francesco (4): fs/ufs: Use the offset_in_page() helper fs/ufs: Change the signature of ufs_get_page() fs/ufs: Use ufs_put_page() in ufs_rename() fs/ufs: Replace kmap() with kmap_local_page() fs/ufs/dir.c | 131 +++++++++++++++++++++++++++---------------------- fs/ufs/namei.c | 11 ++--- fs/ufs/ufs.h | 1 + 3 files changed, 78 insertions(+), 65 deletions(-)