Pushed a version (hopefully) fixing Tom's complaints.
On 2015-01-28 13:52:30 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-28 13:38:51 -0500, Tom Lane wrote:
> >> #define BUFFERDESC_PADDED_SIZE (SIZEOF_VOID_P == 8 ? 64 : 32)
>
> > Hm, did you intentionally put a 32in there or
Andres Freund writes:
> On 2015-01-28 13:38:51 -0500, Tom Lane wrote:
>> #define BUFFERDESC_PADDED_SIZE (SIZEOF_VOID_P == 8 ? 64 : 32)
> Hm, did you intentionally put a 32in there or was that just the logical
> continuation of 64? Because there's no way it'll ever fit into 32 bytes
> in the
On 2015-01-28 13:38:51 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> I personally still think that a comment above sbufdesc's definition
> >> would be sufficient for now. But whatever. I'll enforce 64byte padding
> >> on 64bit platforms, and do nothing on 32bit platforms.
>
> > Patch doing
Andres Freund writes:
>> I personally still think that a comment above sbufdesc's definition
>> would be sufficient for now. But whatever. I'll enforce 64byte padding
>> on 64bit platforms, and do nothing on 32bit platforms.
> Patch doing that attached.
Surely the sizeof() in BufferShmemSize nee
On 2015-01-28 17:08:46 +0100, Andres Freund wrote:
> I just have no idea whether it'd be beneficial to use more space on
> 32bit to pad the individual entries. Since this mostly is beneficial on
> multi-socket, highly concurrent workloads, I doubt it really matter.
> I personally still think that
On 2015-01-28 10:58:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-28 10:35:28 -0500, Tom Lane wrote:
> >> Even if you didn't have plans like that, it would be entire folly to
> >> imagine that buffer headers will be exactly 64 bytes without some forcing
> >> function for that.
>
Andres Freund writes:
> On 2015-01-28 10:35:28 -0500, Tom Lane wrote:
>> Even if you didn't have plans like that, it would be entire folly to
>> imagine that buffer headers will be exactly 64 bytes without some forcing
>> function for that.
> Meh. The 128 byte additionally used by the alignment d
On 2015-01-28 10:35:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
> >> So maybe we should also do something like what LWLocks do, and make a
> >> union between the actual structure and an appropriate array of padding
> >> bytes - say either
On Wed, Jan 28, 2015 at 10:35 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
>>> So maybe we should also do something like what LWLocks do, and make a
>>> union between the actual structure and an appropriate array of padding
>>> bytes - say either
Andres Freund writes:
> On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
>> So maybe we should also do something like what LWLocks do, and make a
>> union between the actual structure and an appropriate array of padding
>> bytes - say either 64 or 128 of them.
> Hm. That's a bit bigger patch. I'm
On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
> On Mon, Jan 26, 2015 at 9:08 PM, Robert Haas wrote:
> >> Contrary opinions? Robert?
> >
> > I'm totally OK with further aligning just that one allocation.
>
> Of course, now that I think about it, aligning it probably works
> mostly because the s
On Mon, Jan 26, 2015 at 9:08 PM, Robert Haas wrote:
>> Contrary opinions? Robert?
>
> I'm totally OK with further aligning just that one allocation.
Of course, now that I think about it, aligning it probably works
mostly because the size is almost exactly one cache line. If it were
any bigger or
On Mon, Jan 26, 2015 at 8:04 PM, Andres Freund wrote:
> On 2015-01-26 19:58:25 -0500, Bruce Momjian wrote:
>> On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
>> > master + 32align.patch:
>> > -c max_connections=400
>> > tps = 183791.872359 (high run vs. run variability)
>> > -c max_
On 2015-01-26 19:58:25 -0500, Bruce Momjian wrote:
> On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
> > master + 32align.patch:
> > -c max_connections=400
> > tps = 183791.872359 (high run vs. run variability)
> > -c max_connections=401
> > tps = 185494.98244 (high run vs. run varia
On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
> master + 32align.patch:
> -c max_connections=400
> tps = 183791.872359 (high run vs. run variability)
> -c max_connections=401
> tps = 185494.98244 (high run vs. run variability)
>
> master + 64align.patch:
> -c max_connections=400
>
On 2015-01-05 21:43:04 -0500, Bruce Momjian wrote:
> On Fri, Jan 2, 2015 at 06:25:52PM +0100, Andres Freund wrote:
> > I can't run tests right now...
> >
> > What exactly do you want to see with these tests? that's essentially
> > what I've already benchmarked + some fprintfs?
>
> I want to test t
On Fri, Jan 2, 2015 at 06:25:52PM +0100, Andres Freund wrote:
> I can't run tests right now...
>
> What exactly do you want to see with these tests? that's essentially
> what I've already benchmarked + some fprintfs?
I want to test two patches that both allocate an extra 64 bytes but
shift the a
On Thu, Jan 1, 2015 at 3:04 PM, Andres Freund wrote:
>>That's true, but if you don't align the beginnings of the allocations,
>>then it's a lot more complicated for the code to properly align stuff
>>within the allocation. It's got to insert a variable amount of
>>padding based on the alignment i
On 2014-12-29 16:59:05 -0500, Bruce Momjian wrote:
> diff --git a/src/backend/storage/buffer/buf_init.c
> b/src/backend/storage/buffer/buf_init.c
> new file mode 100644
> index ff6c713..c4dce5b
> *** a/src/backend/storage/buffer/buf_init.c
> --- b/src/backend/storage/buffer/buf_init.c
> **
On Thu, Jan 1, 2015 at 09:04:48PM +0100, Andres Freund wrote:
> On January 1, 2015 8:49:06 PM CET, Robert Haas wrote:
> >On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund
> >wrote:
> >> The problem is that just aligning the main allocation to some
> >boundary
> >> doesn't mean the hot part of the a
On January 1, 2015 8:49:06 PM CET, Robert Haas wrote:
>On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund
>wrote:
>> The problem is that just aligning the main allocation to some
>boundary
>> doesn't mean the hot part of the allocation is properly aligned.
>shmem.c
>> in fact can't really do much abo
On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund wrote:
> The problem is that just aligning the main allocation to some boundary
> doesn't mean the hot part of the allocation is properly aligned. shmem.c
> in fact can't really do much about that - so fully moving the
> responsibility seems more like
On Thu, Jan 1, 2015 at 05:59:25PM +0100, Andres Freund wrote:
> > That seems like a strange approach. I think it's pretty sensible to
> > try to ensure that allocated blocks of shared memory have decent
> > alignment, and we don't have enough of them for aligning on 64-byte
> > boundaries (or eve
On 2015-01-01 11:55:03 -0500, Robert Haas wrote:
> On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund wrote:
> >> Andres reported the above 2x pgbench difference in February, but no
> >> action was taken as everyone felt there needed to be more performance
> >> testing, but it never happened:
> >
> >
On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund wrote:
>> Andres reported the above 2x pgbench difference in February, but no
>> action was taken as everyone felt there needed to be more performance
>> testing, but it never happened:
>
> FWIW, I have no idea what exactly should be tested there. Rig
On 2014-12-29 16:59:05 -0500, Bruce Momjian wrote:
> I am glad someone else considers this important.
I do consider it important. I just considered the lwlock scalability
more important...
> Andres reported the above 2x pgbench difference in February, but no
> action was taken as everyone felt th
On Sat, Dec 27, 2014 at 08:05:42PM -0500, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 11:20 AM, Andres Freund
> wrote:
> > I just verified that I can still reproduce the problem:
> >
> > # aligned case (max_connections=401)
> > afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres -n -M prepared
On Wed, Dec 24, 2014 at 11:20 AM, Andres Freund wrote:
> I just verified that I can still reproduce the problem:
>
> # aligned case (max_connections=401)
> afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres -n -M prepared -c 96 -j
> 96 -T 100 -S
> progress: 1.0 s, 405170.2 tps, lat 0.195 ms st
On 2014-12-24 10:00:05 -0500, Bruce Momjian wrote:
> On Wed, Dec 24, 2014 at 10:30:19AM +0100, Andres Freund wrote:
> > On 2014-12-23 22:51:22 -0500, Bruce Momjian wrote:
> > > Many of these are 64-byte aligned, including Buffer Descriptors.
> >
> > In that case you need to change max_connections,
On Wed, Dec 24, 2014 at 10:30:19AM +0100, Andres Freund wrote:
> On 2014-12-23 22:51:22 -0500, Bruce Momjian wrote:
> > Many of these are 64-byte aligned, including Buffer Descriptors.
>
> In that case you need to change max_connections, some settings will lead
> to unaligned BufferDescriptors.
W
On 2014-12-23 22:51:22 -0500, Bruce Momjian wrote:
> Many of these are 64-byte aligned, including Buffer Descriptors.
In that case you need to change max_connections, some settings will lead
to unaligned BufferDescriptors.
> I
> tested pgbench with these commands:
>
> $ pgbench -i -s 95 pg
On Thu, Apr 17, 2014 at 11:23:24AM +0200, Andres Freund wrote:
> On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
> > On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
> > > On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
> > > > >> It may well be that your proposal is spot on. But
On Thu, Apr 17, 2014 at 11:23:24AM +0200, Andres Freund wrote:
> On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
> > On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
> > > On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
> > > > >> It may well be that your proposal is spot on. But
On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
> On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
> > On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
> > > >> It may well be that your proposal is spot on. But I'd like to see some
> > > >> data-structure-by-data-structure measure
On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
> On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
> > >> It may well be that your proposal is spot on. But I'd like to see some
> > >> data-structure-by-data-structure measurements, rather than assuming that
> > >> alignment must be a
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
> >> It may well be that your proposal is spot on. But I'd like to see some
> >> data-structure-by-data-structure measurements, rather than assuming that
> >> alignment must be a good thing.
> >
> > I am fine with just aligning BufferDescriptors pro
On Wed, Feb 5, 2014 at 11:37 AM, Andres Freund wrote:
> On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
>> > just wasn't updated in the last 10 years.
>>
>> No, ALIGNOF_BUFFER is there because we r
On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
> > just wasn't updated in the last 10 years.
>
> No, ALIGNOF_BUFFER is there because we read something that said that I/O
> transfers between userspac
Andres Freund writes:
> And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
> just wasn't updated in the last 10 years.
No, ALIGNOF_BUFFER is there because we read something that said that I/O
transfers between userspace and kernel disk cache would be faster with
aligned buffe
39 matches
Mail list logo
