[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-mtk/5.15.0-1030.34 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-mtk' to 'verification-done-jammy- linux-mtk'. If the problem still exists, change the tag 'verification- needed-jammy-linux-mtk' to 'verification-failed-jammy-linux-mtk'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-mtk-v2 verification-needed-jammy-linux-mtk -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-xilinx- zynqmp/5.15.0-1025.29 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-xilinx-zynqmp' to 'verification-done-jammy-linux-xilinx-zynqmp'. If the problem still exists, change the tag 'verification-needed-jammy-linux-xilinx-zynqmp' to 'verification-failed-jammy-linux-xilinx-zynqmp'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-xilinx-zynqmp-v2 verification-needed-jammy-linux-xilinx-zynqmp -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-nvidia- tegra-5.15/5.15.0-1018.18~20.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-focal-linux- nvidia-tegra-5.15' to 'verification-done-focal-linux-nvidia-tegra-5.15'. If the problem still exists, change the tag 'verification-needed-focal- linux-nvidia-tegra-5.15' to 'verification-failed-focal-linux-nvidia- tegra-5.15'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 verification-needed-focal-linux-nvidia-tegra-5.15 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-nvidia-tegra- igx/5.15.0-1005.5 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-nvidia-tegra- igx' to 'verification-done-jammy-linux-nvidia-tegra-igx'. If the problem still exists, change the tag 'verification-needed-jammy-linux-nvidia- tegra-igx' to 'verification-failed-jammy-linux-nvidia-tegra-igx'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 verification-needed-jammy-linux-nvidia-tegra-igx -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux- nvidia-6.2/6.2.0-1011.11 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-nvidia-6.2' to 'verification-done-jammy-linux-nvidia-6.2'. If the problem still exists, change the tag 'verification-needed-jammy-linux-nvidia-6.2' to 'verification-failed-jammy-linux-nvidia-6.2'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-nvidia-6.2-v2 verification-needed-jammy-linux-nvidia-6.2 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux- bluefield/5.15.0-1027.29 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-bluefield' to 'verification-done-jammy-linux-bluefield'. If the problem still exists, change the tag 'verification-needed-jammy-linux-bluefield' to 'verification-failed-jammy-linux-bluefield'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-bluefield-v2 verification-needed-jammy-linux-bluefield -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-raspi/5.15.0-1040.43 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-raspi' to 'verification-done-jammy- linux-raspi'. If the problem still exists, change the tag 'verification- needed-jammy-linux-raspi' to 'verification-failed-jammy-linux-raspi'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-raspi-v2 verification-needed-jammy-linux-raspi -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-nvidia- tegra/5.15.0-1018.18 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-nvidia-tegra' to 'verification-done-jammy-linux-nvidia-tegra'. If the problem still exists, change the tag 'verification-needed-jammy-linux-nvidia-tegra' to 'verification-failed-jammy-linux-nvidia-tegra'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-nvidia-tegra-v2 verification-needed-jammy-linux-nvidia-tegra -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
** Tags removed: verification-needed-jammy-linux-aws ** Tags added: verification-done-jammy-linux-aws -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux- aws-6.2/6.2.0-1014.14~22.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux- aws-6.2' to 'verification-done-jammy-linux-aws-6.2'. If the problem still exists, change the tag 'verification-needed-jammy-linux-aws-6.2' to 'verification-failed-jammy-linux-aws-6.2'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-aws-6.2-v2 verification-needed-jammy-linux-aws-6.2 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-azure/6.2.0-1015.15 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lunar-linux-azure' to 'verification-done-lunar- linux-azure'. If the problem still exists, change the tag 'verification- needed-lunar-linux-azure' to 'verification-failed-lunar-linux-azure'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-lunar-linux-azure-v2 verification-needed-lunar-linux-azure -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-aws/5.15.0-1048.53 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-aws' to 'verification-done-jammy- linux-aws'. If the problem still exists, change the tag 'verification- needed-jammy-linux-aws' to 'verification-failed-jammy-linux-aws'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-aws-v2 verification-needed-jammy-linux-aws -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux-azure/5.15.0-1050.57 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-azure' to 'verification-done-jammy- linux-azure'. If the problem still exists, change the tag 'verification- needed-jammy-linux-azure' to 'verification-failed-jammy-linux-azure'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-azure-v2 verification-needed-jammy-linux-azure -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Status in linux source package in Lunar: Fix Released Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug was fixed in the package linux - 6.2.0-34.34 --- linux (6.2.0-34.34) lunar; urgency=medium * lunar/linux: 6.2.0-34.34 -proposed tracker (LP: #2033779) * CVE-2023-20569 - x86/cpu, kvm: Add support for CPUID_8021_EAX - tools headers x86 cpufeatures: Sync with the kernel sources - x86/alternative: Optimize returns patching - x86/retbleed: Add __x86_return_thunk alignment checks - x86/srso: Add a Speculative RAS Overflow mitigation - x86/srso: Add IBPB_BRTYPE support - x86/srso: Add SRSO_NO support - x86/srso: Add IBPB - x86/srso: Add IBPB on VMEXIT - x86/srso: Fix return thunks in generated code - x86/srso: Add a forgotten NOENDBR annotation - x86/srso: Tie SBPB bit setting to microcode patch detection - Documentation/hw-vuln: Unify filename specification in index - Documentation/srso: Document IBPB aspect and fix formatting - x86/srso: Fix build breakage with the LLVM linker - x86: Move gds_ucode_mitigated() declaration to header - x86/retpoline: Don't clobber RFLAGS during srso_safe_ret() - x86/srso: Disable the mitigation on unaffected configurations - x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG - x86/retpoline,kprobes: Skip optprobe check for indirect jumps with retpolines and IBT - x86/cpu: Fix __x86_return_thunk symbol type - x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk() - objtool/x86: Fix SRSO mess - x86/alternative: Make custom return thunk unconditional - x86/cpu: Clean up SRSO return thunk mess - x86/cpu: Rename original retbleed methods - x86/cpu: Rename srso_(.*)_alias to srso_alias_\1 - x86/cpu: Cleanup the untrain mess - x86/srso: Explain the untraining sequences a bit more - objtool/x86: Fixup frame-pointer vs rethunk - x86/static_call: Fix __static_call_fixup() - x86/srso: Correct the mitigation status when SMT is disabled - Ubuntu: [Config]: enable Speculative Return Stack Overflow mitigation * Please enable Renesas RZ platform serial installer (LP: #2022361) - [Config] enable hihope RZ/G2M serial console - [Config] Mark sh-sci as built-in * dGPU cannot resume because system firmware stuck in IPCS method (LP: #2021572) - drm/i915/tc: Abort DP AUX transfer on a disconnected TC port - drm/i915/tc: switch to intel_de_* register accessors in display code - drm/i915: Enable a PIPEDMC whenever its corresponding pipe is enabled - drm/i915/tc: Fix TC port link ref init for DP MST during HW readout - drm/i915/tc: Fix system resume MST mode restore for DP-alt sinks - drm/i915/tc: Wait for IOM/FW PHY initialization of legacy TC ports - drm/i915/tc: Factor out helpers converting HPD mask to TC mode - drm/i915/tc: Fix target TC mode for a disconnected legacy port - drm/i915/tc: Fix TC mode for a legacy port if the PHY is not ready - drm/i915/tc: Fix initial TC mode on disabled legacy ports - drm/i915/tc: Make the TC mode readout consistent in all PHY states - drm/i915: Add encoder hook to get the PLL type used by TC ports - drm/i915/tc: Assume a TC port is legacy if VBT says the port has HDMI - drm/i915/tc: Factor out a function querying active links on a TC port - drm/i915/tc: Check the PLL type used by an enabled TC port - drm/i915/tc: Group the TC PHY setup/query functions per platform - drm/i915/tc: Use the adlp prefix for ADLP TC PHY functions - drm/i915/tc: Rename tc_phy_status_complete() to tc_phy_is_ready() - drm/i915/tc: Use the tc_phy prefix for all TC PHY functions - drm/i915/tc: Move TC port fields to a new intel_tc_port struct - drm/i915/tc: Check for TC PHY explicitly in intel_tc_port_fia_max_lane_count() - drm/i915/tc: Move the intel_tc_port struct declaration to intel_tc.c - drm/i915/tc: Add TC PHY hook to get the PHY HPD live status - drm/i915/tc: Add TC PHY hooks to get the PHY ready/owned state - drm/i915/tc: Add TC PHY hook to read out the PHY HW state - drm/i915/tc: Add generic TC PHY connect/disconnect handlers - drm/i915/tc: Factor out tc_phy_verify_legacy_or_dp_alt_mode() - drm/i915/tc: Add TC PHY hooks to connect/disconnect the PHY - drm/i915/tc: Fix up the legacy VBT flag only in disconnected mode - drm/i915/tc: Check TC mode instead of the VBT legacy flag - drm/i915/tc: Block/unblock TC-cold in the PHY connect/disconnect hooks - drm/i915/tc: Remove redundant wakeref=0 check from unblock_tc_cold() - drm/i915/tc: Drop tc_cold_block()/unblock()'s power domain parameter - drm/i915/tc: Add TC PHY hook to get the TC-cold blocking power domain - drm/i915/tc: Add asserts in TC PHY hooks that the required power is on - drm/i915/tc: Add TC PHY hook to init the PHY - drm/i915/adlp/tc: Use the DE HPD ISR register for hotplug detection - drm/i915/tc: Get power ref for reading the HPD live status register
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug was fixed in the package linux - 5.15.0-86.96 --- linux (5.15.0-86.96) jammy; urgency=medium * jammy/linux: 5.15.0-86.96 -proposed tracker (LP: #2036575) * 5.15.0-85 live migration regression (LP: #2036675) - Revert "KVM: x86: Always enable legacy FP/SSE in allowed user XFEATURES" - Revert "x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0" * Regression for ubuntu_bpf test build on Jammy 5.15.0-85.95 (LP: #2035181) - selftests/bpf: fix static assert compilation issue for test_cls_*.c * `refcount_t: underflow; use-after-free.` on hidon w/ 5.15.0-85-generic (LP: #2034447) - crypto: rsa-pkcs1pad - Use helper to set reqsize linux (5.15.0-85.95) jammy; urgency=medium * jammy/linux: 5.15.0-85.95 -proposed tracker (LP: #2033821) * Please enable Renesas RZ platform serial installer (LP: #2022361) - [Config] enable hihope RZ/G2M serial console - [Config] Mark sh-sci as built-in * Request backport of xen timekeeping performance improvements (LP: #2033122) - x86/xen/time: prefer tsc as clocksource when it is invariant * kdump doesn't work with UEFI secure boot and kernel lockdown enabled on ARM64 (LP: #2033007) - [Config]: Enable CONFIG_KEXEC_IMAGE_VERIFY_SIG - kexec, KEYS: make the code in bzImage64_verify_sig generic - arm64: kexec_file: use more system keyrings to verify kernel image signature * ubuntu_kernel_selftests:net:vrf-xfrm-tests.sh: 8 failed test cases on jammy/fips (LP: #2019880) - selftests: net: vrf-xfrm-tests: change authentication and encryption algos * ubuntu_kernel_selftests:net:tls: 88 failed test cases on jammy/fips (LP: #2019868) - selftests/harness: allow tests to be skipped during setup - selftests: net: tls: check if FIPS mode is enabled * A general-proteciton exception during guest migration to unsupported PKRU machine (LP: 2032164, reverted) - x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0 - KVM: x86: Always enable legacy FP/SSE in allowed user XFEATURES * CVE-2023-4569 - netfilter: nf_tables: deactivate catchall elements in next generation * CVE-2023-20569 - x86/cpu, kvm: Add support for CPUID_8021_EAX - x86/srso: Add a Speculative RAS Overflow mitigation - x86/srso: Add IBPB_BRTYPE support - x86/srso: Add SRSO_NO support - x86/srso: Add IBPB - x86/srso: Add IBPB on VMEXIT - x86/srso: Fix return thunks in generated code - x86/srso: Tie SBPB bit setting to microcode patch detection - x86: fix backwards merge of GDS/SRSO bit - x86/srso: Fix build breakage with the LLVM linker - x86/cpu: Fix __x86_return_thunk symbol type - x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk() - x86/alternative: Make custom return thunk unconditional - objtool: Add frame-pointer-specific function ignore - x86/ibt: Add ANNOTATE_NOENDBR - x86/cpu: Clean up SRSO return thunk mess - x86/cpu: Rename original retbleed methods - x86/cpu: Rename srso_(.*)_alias to srso_alias_\1 - x86/cpu: Cleanup the untrain mess - x86/srso: Explain the untraining sequences a bit more - x86/static_call: Fix __static_call_fixup() - x86/retpoline: Don't clobber RFLAGS during srso_safe_ret() - x86/srso: Disable the mitigation on unaffected configurations - x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG - objtool/x86: Fixup frame-pointer vs rethunk - x86/srso: Correct the mitigation status when SMT is disabled - objtool/x86: Fix SRSO mess - Ubuntu: [Config]: enable Speculative Return Stack Overflow mitigation * Fix unreliable ethernet cable detection on I219 NIC (LP: #2028122) - e1000e: Use PME poll to circumvent unreliable ACPI wake * Need to get fine-grained control for FAN(TFN) Participant. (LP: #2031333) - ACPI: fan: Separate file for attributes creation - ACPI: fan: Optimize struct acpi_fan_fif - ACPI: fan: Properly handle fine grain control - ACPI: fan: Add additional attributes for fine grain control * [SRU][Ubuntu 22.04.1] Unable to interpret the frequency values in cpuinfo_min_freq and cpuino_max_freq sysfs files. (LP: #2030924) - cpufreq: intel_pstate: Fix scaling for hybrid-capable * CVE-2023-40283 - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_ready_cb * CVE-2023-20588 - x86/bugs: Increase the x86 bugs vector size to two u32s - x86/CPU/AMD: Do not leak quotient data after a division by 0 - x86/CPU/AMD: Fix the DIV(0) initial fix attempt * CVE-2023-4194 - net: tun_chr_open(): set sk_uid from current_fsuid() - net: tap_open(): set sk_uid from current_fsuid() * CVE-2023-4155 - KVM: SEV: Refactor out sev_es_state struct - KVM: SEV: Fall back to vmalloc for SEV-ES scratch area if necessary - KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure - KVM: SVM: Exit to userspace on ENOMEM/EFAULT GHCB
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
Thanks, booted both kernels on i3 instances that reported support for invariant tsc and had nomigrate set and was able to validate that both selected the tsc instead of xen as the clocksource. ** Tags removed: verification-needed-jammy-linux verification-needed-lunar-linux ** Tags added: verification-done-jammy-linux verification-done-lunar-linux -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux/6.2.0-34.34 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lunar-linux' to 'verification-done-lunar-linux'. If the problem still exists, change the tag 'verification-needed-lunar- linux' to 'verification-failed-lunar-linux'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-lunar-linux-v2 verification-needed-lunar-linux -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
This bug is awaiting verification that the linux/5.15.0-85.95 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux' to 'verification-done-jammy-linux'. If the problem still exists, change the tag 'verification-needed-jammy- linux' to 'verification-failed-jammy-linux'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-jammy-linux-v2 verification-needed-jammy-linux -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2033122] Re: Request backport of xen timekeeping performance improvements
** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Jammy) Status: New => Fix Committed ** Changed in: linux (Ubuntu Lunar) Status: New => Fix Committed ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Lunar) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Krister Johansen (kmjohansen) ** Changed in: linux (Ubuntu Lunar) Assignee: (unassigned) => Krister Johansen (kmjohansen) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2033122 Title: Request backport of xen timekeeping performance improvements Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Status in linux source package in Lunar: Fix Committed Bug description: Users, especially those on EC2, are encouraged to select tsc as their default clocksource. However, this requires manual tuning of the operating system. Kvm can determine if it safe to use the tsc, and will default to that instead of its pvclock when appropriate. This requests a backport of patch does the same for Xen instances. If appropriate, it's fine if this is applied to only the linux-aws branches. Not all Xen EC2 instances advertise explicit nomigrate support, however, on those that do we'll select tsc by default. On the subset of hosts where this is advertised, users will safely default to the more performant clocksource. [Impact] Xen instances default to the xen clocksource which has been documented to be slower. This is required for instances where the tsc is not safe to use, or the guest is subject to migration. On some platforms the performance impact can be high, and users are encouraged to select the tsc when appropriate. Instead of leaving up to users to figure this out by reading a variety of different documents, pick the fast clocksource when it can be determined to be safe to do so. [Backport] Clean cherry pick. No conflicts applying to 5.15 or 6.2. [Test] Booted EC2 xen instances with and without this patch and validated that on those that properly advertised the required criteria via cpuid, that the clocksource defaulted to tsc instead of xen. [Potential Regression] Potential is low, since only absurd configurations could lead to a problem. If this is considered risky, it can be applied to only linux-aws where the documented guidance is for users to enable tsc as the clocksource on Xen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2033122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
