| Message ID | 20230601190938.1040712-1-khalid.elmously@canonical.com |
|---|---|
| Headers | show |
| Series | Make new NFS cache behaviour opt-in | expand |
Hi, On Thu, 1 Jun 2023 at 20:11, Khalid Elmously <khalid.elmously@canonical.com> wrote: > > BugLink: https://bugs.launchpad.net/bugs/2022098 > > The fix to LP #2003053 has caused massively increased NFS server access in some use-cases, which caused severe performance degradation to the point of being unusable. > > The solution to this issue, at least temporarily and at least for linux-gke, is to make the new behaviour optional using the "nfs_fasc=1" module parameter. Without this parameter specified, (or specified as =0) will keep the old behaviour. > I like this approach as it maintains status-quo for most people, yet has a runtime option for those that are affected by 2003053. We should mention this incoming change to users that are affected by 2003053. Nothing in this issue is unique to linux-gke kernel - and likely happens to be a canary as an early adopter. I believe we are / will experience similar issue on other kernels. Separately GKE product can be deployed with other kernels too. My preference is to apply this patch series to: j/f linux-gke for a quicker respin. But also apply it to all generic kernels, as a sauce patch mantic..focal:linux-generic (and any other top levels that have this code). > > Thanks Thadeu for the feedback and the original inspiration for this fix. > > > Testing: > - Used a slightly modified version of this patch (which simply logs whether the new or the old behaviour is taking effect) on an NFS client to confirm that 'modprobe nfs' and 'modprobe nfs nfs_fasc=0' maintain the old behaviour, and that 'modprobe nfs nfs_fasc=1' implements the new cache behaviour. > Ack. > > Regresion potential: > - Regression potential is considered low considering the scope of the change and is limited to NFS only. > With prejudice Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> for * [jf:linux-gke] fast track * [m-f:linux-generic] next cycle Regards, Dimitri.
On 6/1/23 1:09 PM, Khalid Elmously wrote: > BugLink: https://bugs.launchpad.net/bugs/2022098 > > The fix to LP #2003053 has caused massively increased NFS server access in some use-cases, which caused severe performance degradation to the point of being unusable. > > The solution to this issue, at least temporarily and at least for linux-gke, is to make the new behaviour optional using the "nfs_fasc=1" module parameter. Without this parameter specified, (or specified as =0) will keep the old behaviour. > > > Thanks Thadeu for the feedback and the original inspiration for this fix. > > > Testing: > - Used a slightly modified version of this patch (which simply logs whether the new or the old behaviour is taking effect) on an NFS client to confirm that 'modprobe nfs' and 'modprobe nfs nfs_fasc=0' maintain the old behaviour, and that 'modprobe nfs nfs_fasc=1' implements the new cache behaviour. > > > Regresion potential: > - Regression potential is considered low considering the scope of the change and is limited to NFS only. > > > > > Khalid Elmously (1): > UBUNTU: SAUCE: Make NFS file-access stale cache behaviour opt-in > > fs/nfs/dir.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) > Acked-by: Tim Gardner <tim.gardner@canonical.com> +1 for applying to master kernels focal through mantic.
On Thu, Jun 01, 2023 at 03:09:36PM -0400, Khalid Elmously wrote: > BugLink: https://bugs.launchpad.net/bugs/2022098 > > The fix to LP #2003053 has caused massively increased NFS server access in some use-cases, which caused severe performance degradation to the point of being unusable. > > The solution to this issue, at least temporarily and at least for linux-gke, is to make the new behaviour optional using the "nfs_fasc=1" module parameter. Without this parameter specified, (or specified as =0) will keep the old behaviour. > > > Thanks Thadeu for the feedback and the original inspiration for this fix. > Which was actually based on Chengen Du's original patch. I think he should have been credited as well, and involved in the matter too. > > Testing: > - Used a slightly modified version of this patch (which simply logs whether the new or the old behaviour is taking effect) on an NFS client to confirm that 'modprobe nfs' and 'modprobe nfs nfs_fasc=0' maintain the old behaviour, and that 'modprobe nfs nfs_fasc=1' implements the new cache behaviour. > This is very limited testing, given we have a test cases for #2003053 which should have been taken into account with both nfs_fasc=0 and nfs_fasc=1. Hopefully we get this right before this gets shipped in all our kernels. Cascardo. > > Regresion potential: > - Regression potential is considered low considering the scope of the change and is limited to NFS only. > > > > > Khalid Elmously (1): > UBUNTU: SAUCE: Make NFS file-access stale cache behaviour opt-in > > fs/nfs/dir.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) > > -- > 2.34.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On 23/06/01 03:09PM, Khalid Elmously wrote: > BugLink: https://bugs.launchpad.net/bugs/2022098 > > The fix to LP #2003053 has caused massively increased NFS server access in some use-cases, which caused severe performance degradation to the point of being unusable. > > The solution to this issue, at least temporarily and at least for linux-gke, is to make the new behaviour optional using the "nfs_fasc=1" module parameter. Without this parameter specified, (or specified as =0) will keep the old behaviour. > > > Thanks Thadeu for the feedback and the original inspiration for this fix. > > > Testing: > - Used a slightly modified version of this patch (which simply logs whether the new or the old behaviour is taking effect) on an NFS client to confirm that 'modprobe nfs' and 'modprobe nfs nfs_fasc=0' maintain the old behaviour, and that 'modprobe nfs nfs_fasc=1' implements the new cache behaviour. > > > Regresion potential: > - Regression potential is considered low considering the scope of the change and is limited to NFS only. > > > > > Khalid Elmously (1): > UBUNTU: SAUCE: Make NFS file-access stale cache behaviour opt-in > > fs/nfs/dir.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) > > -- > 2.34.1 Acked-by: Andrei Gherzan <andrei.gherzan@canonical.com>
On 01.06.23 21:09, Khalid Elmously wrote: > BugLink: https://bugs.launchpad.net/bugs/2022098 > > The fix to LP #2003053 has caused massively increased NFS server access in some use-cases, which caused severe performance degradation to the point of being unusable. > > The solution to this issue, at least temporarily and at least for linux-gke, is to make the new behaviour optional using the "nfs_fasc=1" module parameter. Without this parameter specified, (or specified as =0) will keep the old behaviour. > > > Thanks Thadeu for the feedback and the original inspiration for this fix. > > > Testing: > - Used a slightly modified version of this patch (which simply logs whether the new or the old behaviour is taking effect) on an NFS client to confirm that 'modprobe nfs' and 'modprobe nfs nfs_fasc=0' maintain the old behaviour, and that 'modprobe nfs nfs_fasc=1' implements the new cache behaviour. > > > Regresion potential: > - Regression potential is considered low considering the scope of the change and is limited to NFS only. > > > > > Khalid Elmously (1): > UBUNTU: SAUCE: Make NFS file-access stale cache behaviour opt-in > > fs/nfs/dir.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) > Applied to jammy,focal:linux-gke/master-next as part of a re-spin from what I gather. There should be a follow-up submission for generic kernels. Thanks. -Stefan