search for: undercommit

...tually looks at Waiman's code... > > Right, this is really different from pvticketlocks, where the *unlock* > primitive wakes up a sleeping VCPU. It is more similar to PLE > (pause-loop exiting). Adding to the discussion, I see there are two possibilities here, considering that in undercommit cases we should not exceed HEAD_SPIN_THRESHOLD, 1. the looping vcpu in pv_head_spin_check() should do halt() considering that we have done enough spinning (more than typical lock-hold time), and hence we are in potential overcommit. 2. multiplex kick_cpu to do directed yield in qspinlock case. Bu...

...tually looks at Waiman's code... > > Right, this is really different from pvticketlocks, where the *unlock* > primitive wakes up a sleeping VCPU. It is more similar to PLE > (pause-loop exiting). Adding to the discussion, I see there are two possibilities here, considering that in undercommit cases we should not exceed HEAD_SPIN_THRESHOLD, 1. the looping vcpu in pv_head_spin_check() should do halt() considering that we have done enough spinning (more than typical lock-hold time), and hence we are in potential overcommit. 2. multiplex kick_cpu to do directed yield in qspinlock case. Bu...

On Fri, September 8, 2017 12:56 pm, hw wrote: > Valeri Galtsev wrote: >> >> On Fri, September 8, 2017 9:48 am, hw wrote: >>> m.roth at 5-cent.us wrote: >>>> hw wrote: >>>>> Mark Haney wrote: >>>> <snip> >>>>>> BTRFS isn't going to impact I/O any more significantly than, say, >>>>>> XFS.

...(0.3) |15150.0 (0.6) | 0.8 | | 1470.0 (2.2) | 1713.7 (1.9) | 16.6 | | 848.6 (4.3) | 967.8 (4.3) | 14.0 | | 652.9 (3.5) | 685.3 (3.7) | 5.0 | +-----------------+----------------+--------+ pvspinlock shows benefits for overcommit ratio > 1 for PLE enabled cases, and undercommits results are flat. non PLE results are much better for smaller VMs. http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/01095.html I would thanks all the experts here for their time in reviewing and commenting on the patch series (including perhaps who have been not listed). Finally special...

...(0.3) |15150.0 (0.6) | 0.8 | | 1470.0 (2.2) | 1713.7 (1.9) | 16.6 | | 848.6 (4.3) | 967.8 (4.3) | 14.0 | | 652.9 (3.5) | 685.3 (3.7) | 5.0 | +-----------------+----------------+--------+ pvspinlock shows benefits for overcommit ratio > 1 for PLE enabled cases, and undercommits results are flat. non PLE results are much better for smaller VMs. http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/01095.html I would thanks all the experts here for their time in reviewing and commenting on the patch series (including perhaps who have been not listed). Finally special...

...(0.3) |15150.0 (0.6) | 0.8 | | 1470.0 (2.2) | 1713.7 (1.9) | 16.6 | | 848.6 (4.3) | 967.8 (4.3) | 14.0 | | 652.9 (3.5) | 685.3 (3.7) | 5.0 | +-----------------+----------------+--------+ pvspinlock shows benefits for overcommit ratio > 1 for PLE enabled cases, and undercommits results are flat. non PLE results are much better for smaller VMs. http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/01095.html I would thanks all the experts here for their time in reviewing and commenting on the patch series (including perhaps who have been not listed). Finally special...

...roring (or if more than 2, raid10 striped mirrors). And I'd probably do it with OS based software raid, as thats more likely to support SSD trim than a hardware raid card, plus allows the host to monitor the SSDs via SMART, which a hardware raid card probably hides. I'd also make sure I undercommit the size of the SSD, so if its a 500GB SSD, I'd make absolutely sure to never have more than 300-350GB of data on it.?? if its part of a stripe set, the only way to ensure this is to partition it so the raid slice is only 300-350GB. -- john r pierce, recycling bits in santa cruz

...ode... >> >> Right, this is really different from pvticketlocks, where the *unlock* >> primitive wakes up a sleeping VCPU. It is more similar to PLE >> (pause-loop exiting). > > Adding to the discussion, I see there are two possibilities here, > considering that in undercommit cases we should not exceed > HEAD_SPIN_THRESHOLD, > > 1. the looping vcpu in pv_head_spin_check() should do halt() > considering that we have done enough spinning (more than typical > lock-hold time), and hence we are in potential overcommit. > > 2. multiplex kick_cpu to do dir...

On 04/07/2014 02:14 AM, Raghavendra K T wrote: > > > I tested the v7,v8 of qspinlock with unfair config on kvm guest. > I was curious about unfair locks performance in undercommit cases. > (overcommit case is expected to perform well) > > But I am seeing hang in overcommit cases. Gdb showed that many vcpus > are halted and there was no progress. Suspecting the problem /race with > halting, I removed the halt() part of kvm_hibernate(). I am yet to > take...

On 04/07/2014 02:14 AM, Raghavendra K T wrote: > > > I tested the v7,v8 of qspinlock with unfair config on kvm guest. > I was curious about unfair locks performance in undercommit cases. > (overcommit case is expected to perform well) > > But I am seeing hang in overcommit cases. Gdb showed that many vcpus > are halted and there was no progress. Suspecting the problem /race with > halting, I removed the halt() part of kvm_hibernate(). I am yet to > take...

On 27/02/14 13:11, Paolo Bonzini wrote: > Il 27/02/2014 13:11, David Vrabel ha scritto: >>> > This patch adds para-virtualization support to the queue spinlock code >>> > by enabling the queue head to kick the lock holder CPU, if known, >>> > in when the lock isn't released for a certain amount of time. It >>> > also enables the mutual

On 27/02/14 13:11, Paolo Bonzini wrote: > Il 27/02/2014 13:11, David Vrabel ha scritto: >>> > This patch adds para-virtualization support to the queue spinlock code >>> > by enabling the queue head to kick the lock holder CPU, if known, >>> > in when the lock isn't released for a certain amount of time. It >>> > also enables the mutual

...My 3ware RAIDs through their 3dm daemon do warn me about SMART status: fail (meaning the drive though working should according to SMART be replaced ASAP). Not certain off hand about LSI ones (one should be able to query them through command line client utility). > > I'd also make sure I undercommit the size of the SSD, so if its a 500GB > SSD, I'd make absolutely sure to never have more than 300-350GB of data > on it.???? if its part of a stripe set, the only way to ensure this is to > partition it so the raid slice is only 300-350GB. Great point! And one may want to adjust stri...

...-- ----------- ---------- > 4-socket 40-core 2316 rec/s 2899 rec/s > Westmere-EX (HT off) > 2-socket 12-core 2130 rec/s 2176 rec/s > Westmere-EP (HT on) > I tested the v7,v8 of qspinlock with unfair config on kvm guest. I was curious about unfair locks performance in undercommit cases. (overcommit case is expected to perform well) But I am seeing hang in overcommit cases. Gdb showed that many vcpus are halted and there was no progress. Suspecting the problem /race with halting, I removed the halt() part of kvm_hibernate(). I am yet to take a closer look at the code on...

...o 1 and MAX size) implementation (inspiration and hint by Paul McKenney) as necessary. - I have found that increasing batch size gives excellent improvements for overcommitted guests. As Rik pointed we may want to further increase batch_size but we need its (side) effect on bigger machine for undercommit cases. - Should we enable it for baremetal too? (As Rik pointed, exploiting NUMA may give more performance) - Should we have config option for batch_size? I would like to thank Rik, Waiman for their review and valuable feedback for V1. Please provide your suggestion and comments. diff --git...

...o 1 and MAX size) implementation (inspiration and hint by Paul McKenney) as necessary. - I have found that increasing batch size gives excellent improvements for overcommitted guests. As Rik pointed we may want to further increase batch_size but we need its (side) effect on bigger machine for undercommit cases. - Should we enable it for baremetal too? (As Rik pointed, exploiting NUMA may give more performance) - Should we have config option for batch_size? I would like to thank Rik, Waiman for their review and valuable feedback for V1. Please provide your suggestion and comments. diff --git...

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit path to use PLE handler V8 of PVspinlock was posted last year. After Avi's suggestions to look at PLE handler's improvements, various optimizations in PLE handling have...

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit path to use PLE handler V8 of PVspinlock was posted last year. After Avi's suggestions to look at PLE handler's improvements, various optimizations in PLE handling have...

This series replaces the existing paravirtualized spinlock mechanism with a paravirtualized ticketlock mechanism. The series provides implementation for both Xen and KVM. Changes in V9: - Changed spin_threshold to 32k to avoid excess halt exits that are causing undercommit degradation (after PLE handler improvement). - Added kvm_irq_delivery_to_apic (suggested by Gleb) - Optimized halt exit path to use PLE handler V8 of PVspinlock was posted last year. After Avi's suggestions to look at PLE handler's improvements, various optimizations in PLE handling have...

...(0.3) |15150.0 (0.6) | 0.8 | | 1470.0 (2.2) | 1713.7 (1.9) | 16.6 | | 848.6 (4.3) | 967.8 (4.3) | 14.0 | | 652.9 (3.5) | 685.3 (3.7) | 5.0 | +-----------------+----------------+--------+ pvspinlock shows benefits for overcommit ratio > 1 for PLE enabled cases, and undercommits results are flat. non PLE results are much better for smaller VMs. http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/01095.html I would thanks all the experts here for their time in reviewing and commenting on the patch series (including perhaps who have been not listed). Finally special...