[Kernel-packages] [Bug 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-09-01 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 4.15.0-115.116

---
linux (4.15.0-115.116) bionic; urgency=medium

  * bionic/linux: 4.15.0-115.116 -proposed tracker (LP: #1893055)

  * [Potential Regression] dscr_inherit_exec_test from powerpc in
ubuntu_kernel_selftests failed on B/E/F (LP: #1888332)
- powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()

linux (4.15.0-114.115) bionic; urgency=medium

  * bionic/linux: 4.15.0-114.115 -proposed tracker (LP: #1891052)

  * ipsec: policy priority management is broken (LP: #1890796)
- xfrm: policy: match with both mark and mask on user interfaces

linux (4.15.0-113.114) bionic; urgency=medium

  * bionic/linux: 4.15.0-113.114 -proposed tracker (LP: #1890705)

  * Packaging resync (LP: #1786013)
- update dkms package versions

  * Reapply "usb: handle warm-reset port requests on hub resume" (LP: #1859873)
- usb: handle warm-reset port requests on hub resume

  * Bionic update: upstream stable patchset 2020-07-29 (LP: #1889474)
- gpio: arizona: handle pm_runtime_get_sync failure case
- gpio: arizona: put pm_runtime in case of failure
- pinctrl: amd: fix npins for uart0 in kerncz_groups
- mac80211: allow rx of mesh eapol frames with default rx key
- scsi: scsi_transport_spi: Fix function pointer check
- xtensa: fix __sync_fetch_and_{and,or}_4 declarations
- xtensa: update *pos in cpuinfo_op.next
- drivers/net/wan/lapbether: Fixed the value of hard_header_len
- net: sky2: initialize return of gm_phy_read
- drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeout
- irqdomain/treewide: Keep firmware node unconditionally allocated
- SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE not waiting for direct IO
  compeletion")
- spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not ours
- IB/umem: fix reference count leak in ib_umem_odp_get()
- uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to 
fix
  GDB regression
- ALSA: info: Drop WARN_ON() from buffer NULL sanity check
- ASoC: rt5670: Correct RT5670_LDO_SEL_MASK
- btrfs: fix double free on ulist after backref resolution failure
- btrfs: fix mount failure caused by race with umount
- btrfs: fix page leaks after failure to lock page for delalloc
- bnxt_en: Fix race when modifying pause settings.
- hippi: Fix a size used in a 'pci_free_consistent()' in an error handling
  path
- ax88172a: fix ax88172a_unbind() failures
- net: dp83640: fix SIOCSHWTSTAMP to update the struct with actual
  configuration
- drm: sun4i: hdmi: Fix inverted HPD result
- net: smc91x: Fix possible memory leak in smc_drv_probe()
- bonding: check error value of register_netdevice() immediately
- mlxsw: destroy workqueue when trap_register in mlxsw_emad_init
- ipvs: fix the connection sync failed in some cases
- i2c: rcar: always clear ICSAR to avoid side effects
- bonding: check return value of register_netdevice() in bond_newlink()
- serial: exar: Fix GPIO configuration for Sealevel cards based on XR17V35X
- scripts/decode_stacktrace: strip basepath from all paths
- HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor override
- HID: apple: Disable Fn-key key-re-mapping on clone keyboards
- dmaengine: tegra210-adma: Fix runtime PM imbalance on error
- Input: add `SW_MACHINE_COVER`
- spi: mediatek: use correct SPI_CFG2_REG MACRO
- regmap: dev_get_regmap_match(): fix string comparison
- hwmon: (aspeed-pwm-tacho) Avoid possible buffer overflow
- dmaengine: ioat setting ioat timeout as module parameter
- Input: synaptics - enable InterTouch for ThinkPad X1E 1st gen
- usb: gadget: udc: gr_udc: fix memleak on error handling path in 
gr_ep_init()
- arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP
- x86: math-emu: Fix up 'cmp' insn for clang ias
- binder: Don't use mmput() from shrinker function.
- usb: xhci-mtk: fix the failure of bandwidth allocation
- usb: xhci: Fix ASM2142/ASM3142 DMA addressing
- Revert "cifs: Fix the target file was deleted when rename failed."
- staging: wlan-ng: properly check endpoint types
- staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
- staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
- staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
- staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
- serial: 8250: fix null-ptr-deref in serial8250_start_tx()
- serial: 8250_mtk: Fix high-speed baud rates clamping
- fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
- vt: Reject zero-sized screen buffer size.
- Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation
- mm/memcg: fix refcount error while moving and swapping
- io-mapping: indicate mapping failure
- parisc: Add atomic64_set_release() 

[Kernel-packages] [Bug 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-08-31 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.4.0-45.49

---
linux (5.4.0-45.49) focal; urgency=medium

  * focal/linux: 5.4.0-45.49 -proposed tracker (LP: #1893050)

  * [Potential Regression] dscr_inherit_exec_test from powerpc in
ubuntu_kernel_selftests failed on B/E/F (LP: #1888332)
- powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()

linux (5.4.0-44.48) focal; urgency=medium

  * focal/linux: 5.4.0-44.48 -proposed tracker (LP: #1891049)

  * Packaging resync (LP: #1786013)
- [Packaging] update helper scripts

  * ipsec: policy priority management is broken (LP: #1890796)
- xfrm: policy: match with both mark and mask on user interfaces

linux (5.4.0-43.47) focal; urgency=medium

  * focal/linux: 5.4.0-43.47 -proposed tracker (LP: #1890746)

  * Packaging resync (LP: #1786013)
- update dkms package versions

  * Devlink -  add RoCE disable kernel support  (LP: #1877270)
- devlink: Add new "enable_roce" generic device param
- net/mlx5: Document flow_steering_mode devlink param
- net/mlx5: Handle "enable_roce" devlink param
- IB/mlx5: Rename profile and init methods
- IB/mlx5: Load profile according to RoCE enablement state
- net/mlx5: Remove unneeded variable in mlx5_unload_one
- net/mlx5: Add devlink reload
- IB/mlx5: Do reverse sequence during device removal

  * msg_zerocopy.sh in net from ubuntu_kernel_selftests failed (LP: #1812620)
- selftests/net: relax cpu affinity requirement in msg_zerocopy test

  * Enlarge hisi_sec2 capability (LP: #1890222)
- Revert "UBUNTU: [Config] Disable hisi_sec2 temporarily"
- crypto: hisilicon - update SEC driver module parameter

  * Fix missing HDMI/DP Audio on an HP Desktop (LP: #1890441)
- ALSA: hda/hdmi: Add quirk to force connectivity

  * Fix IOMMU error on AMD Radeon Pro W5700 (LP: #1890306)
- PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken

  * ASoC:amd:renoir:  the dmic can't record sound after suspend and resume
(LP: #1890220)
- SAUCE: ASoC: amd: renoir: restore two more registers during resume

  * No sound, Dummy output on Acer Swift 3 SF314-57G with Ice Lake core-i7  CPU
(LP: #1877757)
- ASoC: SOF: Intel: hda: fix generic hda codec support

  * Fix right speaker of HP laptop (LP: #1889375)
- SAUCE: hda/realtek: Fix right speaker of HP laptop

  * blk_update_request error when mount nvme partition (LP: #1872383)
- SAUCE: nvme-pci: prevent SK hynix PC400 from using Write Zeroes command

  * soc/amd/renoir: detect dmic from acpi table (LP: #1887734)
- ASoC: amd: add logic to check dmic hardware runtime
- ASoC: amd: add ACPI dependency check
- ASoC: amd: fixed kernel warnings

  * soc/amd/renoir: change the module name to make it work with ucm3
(LP: #1888166)
- AsoC: amd: add missing snd- module prefix to the acp3x-rn driver kernel
  module
- SAUCE: remove a kernel module since its name is changed

  * Focal update: v5.4.55 upstream stable release (LP: #1890343)
- AX.25: Fix out-of-bounds read in ax25_connect()
- AX.25: Prevent out-of-bounds read in ax25_sendmsg()
- dev: Defer free of skbs in flush_backlog
- drivers/net/wan/x25_asy: Fix to make it work
- ip6_gre: fix null-ptr-deref in ip6gre_init_net()
- net-sysfs: add a newline when printing 'tx_timeout' by sysfs
- net: udp: Fix wrong clean up for IS_UDPLITE macro
- qrtr: orphan socket in qrtr_release()
- rtnetlink: Fix memory(net_device) leak when ->newlink fails
- rxrpc: Fix sendmsg() returning EPIPE due to recvmsg() returning ENODATA
- tcp: allow at most one TLP probe per flight
- AX.25: Prevent integer overflows in connect and sendmsg
- sctp: shrink stream outq only when new outcnt < old outcnt
- sctp: shrink stream outq when fails to do addstream reconf
- udp: Copy has_conns in reuseport_grow().
- udp: Improve load balancing for SO_REUSEPORT.
- regmap: debugfs: check count when read regmap file
- PM: wakeup: Show statistics for deleted wakeup sources again
- Revert "dpaa_eth: fix usage as DSA master, try 3"
- Linux 5.4.55

  * Add support for Atlantic NIC firmware v4 (LP: #1886908)
- net: atlantic: simplify hw_get_fw_version() usage
- net: atlantic: align return value of ver_match function with function name
- net: atlantic: add support for FW 4.x

  * perf vendor events s390: Add new deflate counters for IBM z15 (LP: #1888551)
- perf vendor events s390: Add new deflate counters for IBM z15

  * Focal update: v5.4.54 upstream stable release (LP: #1889669)
- soc: qcom: rpmh: Dirt can only make you dirtier, not cleaner
- gpio: arizona: handle pm_runtime_get_sync failure case
- gpio: arizona: put pm_runtime in case of failure
- pinctrl: amd: fix npins for uart0 in kerncz_groups
- mac80211: allow rx of mesh eapol frames with default rx key
- scsi: scsi_transport_spi: Fix function pointer check
- xtensa: fix __sync_fetch_and_{and,or}_4 declarations

[Kernel-packages] [Bug 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-08-25 Thread Gavin Guo
** Tags removed: verification-needed-bionic verification-needed-focal
** Tags added: verification-done-bionic verification-done-focal

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Released
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-08-10 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the 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-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag 'verification-needed-bionic' to 'verification-failed-
bionic'.

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: verification-needed-bionic

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Released
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-08-10 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the 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' to 'verification-done-focal'. If the problem still exists, change
the tag 'verification-needed-focal' to 'verification-failed-focal'.

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: verification-needed-focal

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Released
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-07-27 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.3.0-64.58

---
linux (5.3.0-64.58) eoan; urgency=medium

  * eoan/linux: 5.3.0-64.58 -proposed tracker (LP: #1887088)

  * linux 4.15.0-109-generic network DoS regression vs -108 (LP: #1886668)
- SAUCE: Revert "netprio_cgroup: Fix unlimited memory leak of v2 cgroups"

linux (5.3.0-63.57) eoan; urgency=medium

  * eoan/linux: 5.3.0-63.57 -proposed tracker (LP: #1885495)

  * seccomp_bpf fails on powerpc (LP: #1885757)
- SAUCE: selftests/seccomp: fix ptrace tests on powerpc

  * The thread level parallelism would be a bottleneck when searching for the
shared pmd by using hugetlbfs (LP: #1882039)
- hugetlbfs: take read_lock on i_mmap for PMD sharing

  * Eoan update: upstream stable patchset 2020-06-30 (LP: #1885775)
- ipv6: fix IPV6_ADDRFORM operation logic
- net_failover: fixed rollback in net_failover_open()
- bridge: Avoid infinite loop when suppressing NS messages with invalid
  options
- vxlan: Avoid infinite loop when suppressing NS messages with invalid 
options
- tun: correct header offsets in napi frags mode
- Input: mms114 - fix handling of mms345l
- ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook
- sched/fair: Don't NUMA balance for kthreads
- Input: synaptics - add a second working PNP_ID for Lenovo T470s
- drivers/net/ibmvnic: Update VNIC protocol version reporting
- powerpc/xive: Clear the page tables for the ESB IO mapping
- ath9k_htc: Silence undersized packet warnings
- RDMA/uverbs: Make the event_queue fds return POLLERR when disassociated
- x86/cpu/amd: Make erratum #1054 a legacy erratum
- perf probe: Accept the instance number of kretprobe event
- mm: add kvfree_sensitive() for freeing sensitive data objects
- aio: fix async fsync creds
- x86_64: Fix jiffies ODR violation
- x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs
- x86/speculation: Prevent rogue cross-process SSBD shutdown
- x86/reboot/quirks: Add MacBook6,1 reboot quirk
- efi/efivars: Add missing kobject_put() in sysfs entry creation error path
- ALSA: es1688: Add the missed snd_card_free()
- ALSA: hda/realtek - add a pintbl quirk for several Lenovo machines
- ALSA: usb-audio: Fix inconsistent card PM state after resume
- ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt
  Dock
- ACPI: sysfs: Fix reference count leak in acpi_sysfs_add_hotplug_profile()
- ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()
- ACPI: GED: add support for _Exx / _Lxx handler methods
- ACPI: PM: Avoid using power resources if there are none for D0
- nilfs2: fix null pointer dereference at nilfs_segctor_do_construct()
- spi: dw: Fix controller unregister order
- spi: bcm2835aux: Fix controller unregister order
- spi: bcm-qspi: when tx/rx buffer is NULL set to 0
- PM: runtime: clk: Fix clk_pm_runtime_get() error path
- crypto: cavium/nitrox - Fix 'nitrox_get_first_device()' when ndevlist is
  fully iterated
- ALSA: pcm: disallow linking stream to itself
- x86/{mce,mm}: Unmap the entire page if the whole page is affected and
  poisoned
- KVM: x86: Fix APIC page invalidation race
- KVM: x86/mmu: Consolidate "is MMIO SPTE" code
- KVM: x86: only do L1TF workaround on affected processors
- x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced
  IBRS.
- x86/speculation: PR_SPEC_FORCE_DISABLE enforcement for indirect branches.
- spi: Fix controller unregister order
- spi: pxa2xx: Fix controller unregister order
- spi: bcm2835: Fix controller unregister order
- spi: pxa2xx: Fix runtime PM ref imbalance on probe error
- crypto: virtio: Fix use-after-free in 
virtio_crypto_skcipher_finalize_req()
- crypto: virtio: Fix src/dst scatterlist calculation in
  __virtio_crypto_skcipher_do_req()
- crypto: virtio: Fix dest length calculation in
  __virtio_crypto_skcipher_do_req()
- selftests/net: in rxtimestamp getopt_long needs terminating null entry
- ovl: initialize error in ovl_copy_xattr
- proc: Use new_inode not new_inode_pseudo
- video: fbdev: w100fb: Fix a potential double free.
- KVM: nSVM: fix condition for filtering async PF
- KVM: nSVM: leave ASID aside in copy_vmcb_control_area
- KVM: nVMX: Consult only the "basic" exit reason when routing nested exit
- KVM: MIPS: Define KVM_ENTRYHI_ASID to cpu_asid_mask(_cpu_data)
- KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits
- KVM: arm64: Make vcpu_cp1x() work on Big Endian hosts
- scsi: megaraid_sas: TM command refire leads to controller firmware crash
- ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
- ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
- ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
- ath9k: Fix general protection fault in 

[Kernel-packages] [Bug 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-07-07 Thread Gavin Guo
** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-07-03 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the 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-
eoan' to 'verification-done-eoan'. If the problem still exists, change
the tag 'verification-needed-eoan' to 'verification-failed-eoan'.

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: verification-needed-eoan

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-07-01 Thread Kleber Sacilotto de Souza
** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Eoan)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-06-10 Thread Nivedita Singhvi
** Changed in: linux (Ubuntu Bionic)
   Importance: Medium => High

** Changed in: linux (Ubuntu Bionic)
   Status: Triaged => In Progress

** Changed in: linux (Ubuntu Eoan)
   Status: Triaged => In Progress

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => Gavin Guo (mimi0213kimo)

** Changed in: linux (Ubuntu Focal)
   Status: Triaged => In Progress

** Changed in: linux (Ubuntu Focal)
   Importance: Medium => High

** Changed in: linux (Ubuntu Eoan)
   Importance: Medium => High

** Changed in: linux (Ubuntu)
   Importance: Medium => High

** Changed in: linux (Ubuntu Eoan)
 Assignee: (unassigned) => Gavin Guo (mimi0213kimo)

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Gavin Guo (mimi0213kimo)

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-06-10 Thread Stefan Bader
For the current development this will be automatically fixed once the
kernel moves to 5.7 (the fix was in 5.5). I leave it to the devel team
whether they want to keep the task open until then.

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: linux (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Eoan)
   Status: New => Triaged

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
   Status: New => Triaged

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu)
   Status: Incomplete => In Progress

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  Triaged
Status in linux source package in Eoan:
  Triaged
Status in linux source package in Focal:
  Triaged

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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 1882039] Re: The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs

2020-06-04 Thread Gavin Guo
** Also affects: linux (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Bionic)
   Importance: Undecided
   Status: New

-- 
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/1882039

Title:
  The thread level parallelism would be a bottleneck when searching for
  the shared pmd by using hugetlbfs

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  New
Status in linux source package in Eoan:
  New
Status in linux source package in Focal:
  New

Bug description:
  [Impact]

  There is performance overhead observed when many threads
  are using hugetlbfs in the database environment.

  [Fix]

  bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing

  The patch improves the locking by using the read lock instead of the
  write lock. And it allows multiple threads searching the suitable shared
  VMA. As there is no modification inside the searching process. The 
  improvement increases the parallelism and decreases the waiting time of
  the other threads.

  [Test]

  The customer stand-up a database with seed data. Then they have a
  loading "driver" which makes a bunch of connections that look like user
  workflows from the database perspective. Finally, the measuring response
  times improvement can be observed for these "users" as well as various
  other metrics at the database level.

  [Regression Potential]

  The modification is only in replacing the write lock to a read one. And 
  there is no modification inside the loop. The regression probability is
  low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+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