Sean, to the issue that you are describing it is also might be possible to
do it some other way around. One, perhaps more portable, is to share a
connected socketpair between two communicating processes, so that you can
do non-blocking read on one of its ends from time to time and check if it
retur
Small nit:
PostgreSQL used SYSV because it allowed for the detection of dead processes.
If you `kill -9`’ed a process, PostgreSQL can detect that and then shut down
and perform an automatic recovery. In this regard, sysv is pretty clever. The
move to POSIX shared mem was done for a host of r
On Wed, Jun 22, 2016 at 07:26:52AM -0700, Maxim Sobolev wrote:
> Konstantin,
> Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. So
> the window of opportunity for the leakage is quite small, much smaller than
> for SYSV primitives. Sorry for missing your status update messag
Konstantin,
Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. So
the window of opportunity for the leakage is quite small, much smaller than
for SYSV primitives. Sorry for missing your status update message, I've
missed it somehow.
mySem = sem_open(semna
On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote:
> Thanks, Konstantin for the great work, we are definitely looking forward to
> get all those improvements to be part of the default FreeBSD kernel/port.
> Would be nice if you can post an update some day later as to what's
> integrated
Thanks, Konstantin for the great work, we are definitely looking forward to
get all those improvements to be part of the default FreeBSD kernel/port.
Would be nice if you can post an update some day later as to what's
integrated and what's not.
Just in case, I've opened #14206 with PG to switch us
On Friday, June 03, 2016 11:29:03 AM Adrian Chadd wrote:
> On 3 June 2016 at 11:27, Adrian Chadd wrote:
>
> > That and the other NUMA stuff is something to address in -12.
>
> And, I completely welcome continued development in NUMA scaling in
> combination with discussion. The iterator changes I
On 3 June 2016 at 11:27, Adrian Chadd wrote:
> That and the other NUMA stuff is something to address in -12.
And, I completely welcome continued development in NUMA scaling in
combination with discussion. The iterator changes I committed are a
more generic version of a patch people were applying
On 3 June 2016 at 10:55, Konstantin Belousov wrote:
> On Fri, Jun 03, 2016 at 11:29:13AM -0600, Alan Somers wrote:
>> On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov
>> wrote:
>> > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote:
>> >> I notice that, with the exception of the VM_
On Fri, Jun 03, 2016 at 11:29:13AM -0600, Alan Somers wrote:
> On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov
> wrote:
> > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote:
> >> I notice that, with the exception of the VM_PHYSSEG_MAX change, these
> >> patches never made it into h
On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov
wrote:
> On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote:
>> I notice that, with the exception of the VM_PHYSSEG_MAX change, these
>> patches never made it into head or ports. Are they unsuitable for low
>> core-count machines, or i
On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote:
> I notice that, with the exception of the VM_PHYSSEG_MAX change, these
> patches never made it into head or ports. Are they unsuitable for low
> core-count machines, or is there some other reason not to commit them?
> If not, what woul
> >>> A couple small steps have been taken toward eliminating the need for
> >>> this
> >>> hack: the addition of the "page size index" field to struct vm_page and
> >>> the
> >>> addition of a similarly named parameter to pmap_enter(). However, at
> >>> the
> >>> moment, the only ta
On Thu, Aug 14, 2014 at 12:19 PM, Alan Cox wrote:
> On 08/14/2014 10:47, John Baldwin wrote:
>> On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
>>> On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote:
>>>
On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
> Hi!
>
>>>
On 08/14/2014 10:47, John Baldwin wrote:
> On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
>> On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote:
>>
>>> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
Hi!
On 16 July 2014 06:29, Konstantin Belousov wrote:
>
On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
> On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote:
>
> > On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
> > > Hi!
> > >
> > >
> > > On 16 July 2014 06:29, Konstantin Belousov wrote:
> > > > On Fri, Jun 27, 2014 at 03:56:13P
On Tuesday, August 12, 2014 5:36:26 pm Adrian Chadd wrote:
> On 12 August 2014 11:09, John Baldwin wrote:
> > On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
> >> Hi!
> >>
> >>
> >> On 16 July 2014 06:29, Konstantin Belousov wrote:
> >> > On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konst
On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote:
> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
> > Hi!
> >
> >
> > On 16 July 2014 06:29, Konstantin Belousov wrote:
> > > On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
> > >> Hi,
> > >> I did some measurem
On Wed, Aug 13, 2014 at 4:58 AM, David Chisnall
wrote:
> On 12 Aug 2014, at 19:09, John Baldwin wrote:
>
> > OTOH, I have actually seen junk profiling _improve_ performance in
> certain
> > cases as it forces promotion of allocated pages to superpages since all
> pages
> > are dirtied. (I have
On 12 Aug 2014, at 19:09, John Baldwin wrote:
> OTOH, I have actually seen junk profiling _improve_ performance in certain
> cases as it forces promotion of allocated pages to superpages since all pages
> are dirtied. (I have a local hack that adds a new malloc option to
> explicitly
> memse
On 12 August 2014 11:09, John Baldwin wrote:
> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
>> Hi!
>>
>>
>> On 16 July 2014 06:29, Konstantin Belousov wrote:
>> > On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
>> >> Hi,
>> >> I did some measurements and hacks t
On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
> Hi!
>
>
> On 16 July 2014 06:29, Konstantin Belousov wrote:
> > On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
> >> Hi,
> >> I did some measurements and hacks to see about the performance and
> >> scalability of P
Am Thu, 17 Jul 2014 20:15:39 +0430
Hooman Fazaeli schrieb:
> On 7/16/2014 5:59 PM, Konstantin Belousov wrote:
> > On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
> >> Hi,
> >> I did some measurements and hacks to see about the performance and
> >> scalability of PostgreSQL 9.
On 7/16/2014 5:59 PM, Konstantin Belousov wrote:
On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
Hi,
I did some measurements and hacks to see about the performance and
scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
Foundation.
The results are described i
Hi!
On 16 July 2014 06:29, Konstantin Belousov wrote:
> On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
>> Hi,
>> I did some measurements and hacks to see about the performance and
>> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
>> Foundation.
>>
>> The
On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
> Hi,
> I did some measurements and hacks to see about the performance and
> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
> Foundation.
>
> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf
Thanks for this.
The cpu_search problem you reference came up here at Isilon as well. Here's a
patch which should get clang to do the "right thing" (inlining 3 specialized
copies of cpu_search); I haven't checked to make sure it doesn't hurt gcc,
though.
Anton
Index: sched_ule.c
On Sat, Jun 28, 2014 at 01:37:20PM +0200, Palle Girgensohn wrote:
>
>
> > 28 jun 2014 kl. 12:21 skrev Konstantin Belousov :
> >
> >> On Sat, Jun 28, 2014 at 12:08:39PM +0200, Palle Girgensohn wrote:
> >>
> >>
> >>> 27 jun 2014 kl. 18:34 skrev Konstantin Belousov :
> >>>
> On Fri, Jun 27,
> 28 jun 2014 kl. 12:21 skrev Konstantin Belousov :
>
>> On Sat, Jun 28, 2014 at 12:08:39PM +0200, Palle Girgensohn wrote:
>>
>>
>>> 27 jun 2014 kl. 18:34 skrev Konstantin Belousov :
>>>
On Fri, Jun 27, 2014 at 10:57:53AM -0400, John Baldwin wrote:
> On Friday, June 27, 2014 8:56:13
On Sat, Jun 28, 2014 at 12:08:39PM +0200, Palle Girgensohn wrote:
>
>
> 27 jun 2014 kl. 18:34 skrev Konstantin Belousov :
>
> > On Fri, Jun 27, 2014 at 10:57:53AM -0400, John Baldwin wrote:
> >> On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote:
> >>> Hi,
> >>> I did some measurement
27 jun 2014 kl. 18:34 skrev Konstantin Belousov :
> On Fri, Jun 27, 2014 at 10:57:53AM -0400, John Baldwin wrote:
>> On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote:
>>> Hi,
>>> I did some measurements and hacks to see about the performance and
>>> scalability of PostgreSQL 9.3 on
On Fri, Jun 27, 2014 at 10:57:53AM -0400, John Baldwin wrote:
> On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote:
> > Hi,
> > I did some measurements and hacks to see about the performance and
> > scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
> > Foundation.
> >
>
On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote:
> Hi,
> I did some measurements and hacks to see about the performance and
> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
> Foundation.
>
> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
> Th
On 27/06/2014 14:56, Konstantin Belousov wrote:
Hi,
I did some measurements and hacks to see about the performance and
scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
Foundation.
The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
The uncommitted patches, refe
June 27 2014 7:56 AM, "Konstantin Belousov" wrote:
> Hi,
> I did some measurements and hacks to see about the performance and
> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
> Foundation.
>
> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
> The uncommi
35 matches
Mail list logo
