On Sat, 18 Apr 2020 at 03:30, Thomas Munro wrote:
>
> On Sat, Apr 18, 2020 at 2:00 AM Ants Aasma wrote:
> > On Thu, 16 Apr 2020 at 10:33, Pavel Stehule wrote:
> > > what I know, pgbench cannot be used for testing spinlocks problems.
> > >
> > > Maybe you can see this issue when a) use higher num
On Sat, Apr 18, 2020 at 2:00 AM Ants Aasma wrote:
> On Thu, 16 Apr 2020 at 10:33, Pavel Stehule wrote:
> > what I know, pgbench cannot be used for testing spinlocks problems.
> >
> > Maybe you can see this issue when a) use higher number clients - hundreds,
> > thousands. Decrease share memory,
On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar wrote:
> Not relevant to the PAUSE stuff Note that when the parallel
> clients reach from 24 to 32 (which equals the machine CPUs), the TPS
> shoots from 454189 to 1097592 which is more than double speed gain
> with just a 30% increase in paralle
On Thu, 16 Apr 2020 at 10:33, Pavel Stehule wrote:
> what I know, pgbench cannot be used for testing spinlocks problems.
>
> Maybe you can see this issue when a) use higher number clients - hundreds,
> thousands. Decrease share memory, so there will be press on related spin lock.
There really ar
čt 16. 4. 2020 v 9:18 odesílatel Amit Khandekar
napsal:
> On Mon, 13 Apr 2020 at 20:16, Amit Khandekar
> wrote:
> > On Sat, 11 Apr 2020 at 04:18, Tom Lane wrote:
> > >
> > > I wrote:
> > > > A more useful test would be to directly experiment with contended
> > > > spinlocks. As I recall, we ha
On Mon, 13 Apr 2020 at 20:16, Amit Khandekar wrote:
> On Sat, 11 Apr 2020 at 04:18, Tom Lane wrote:
> >
> > I wrote:
> > > A more useful test would be to directly experiment with contended
> > > spinlocks. As I recall, we had some test cases laying about when
> > > we were fooling with the spin
On Sat, 11 Apr 2020 at 04:18, Tom Lane wrote:
>
> I wrote:
> > A more useful test would be to directly experiment with contended
> > spinlocks. As I recall, we had some test cases laying about when
> > we were fooling with the spin delay stuff on Intel --- maybe
> > resurrecting one of those woul
On Sat, 11 Apr 2020 at 00:47, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
> > On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
> > using a sample C program (attached spin.c). Here, many child processes
> > (much more than CPUs) wait in a ti
I wrote:
> A more useful test would be to directly experiment with contended
> spinlocks. As I recall, we had some test cases laying about when
> we were fooling with the spin delay stuff on Intel --- maybe
> resurrecting one of those would be useful?
The last really significant performance testi
Andres Freund writes:
> On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
>> On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
>> using a sample C program (attached spin.c).
> PAUSE doesn't operate on the level of the CPU scheduler. So the OS won't
> just schedule another proces
Hi,
On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
> On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
> using a sample C program (attached spin.c). Here, many child processes
> (much more than CPUs) wait in a tight loop for a shared variable to
> become 0, while the parent pr
Hi,
We use (an equivalent of) the PAUSE instruction in spin_delay() for
Intel architectures. The goal is to slow down the spinlock tight loop
and thus prevent it from eating CPU and causing CPU starvation, so
that other processes get their fair share of the CPU time. Intel
documentation [1] clearl
12 matches
Mail list logo
