On Thu, Jul 28, 2011 at 11:05 PM, Noah Misch wrote:
> The comparison I had in mind was (a) master + lazy-vxid + [1]sinval-fastpath
> vs. (b) master + lazy-vxid + [2]sinval-hasmessages. The only claimed benefit
> of
> [2] over [1], as far as I can see, is invulnerability to the hazard described
On Thu, Jul 28, 2011 at 03:03:05PM -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 10:05 AM, Robert Haas wrote:
> >> I'll also test out creating and dropping some tables.
> >
> > Still need to work on this one.
>
> And there results are in. I set up the following sophisticated test
> script
On Thu, Jul 28, 2011 at 10:05 AM, Robert Haas wrote:
>> I'll also test out creating and dropping some tables.
>
> Still need to work on this one.
And there results are in. I set up the following sophisticated test
script for pgbench:
CREATE TEMP TABLE foo (a int);
DROP TABLE foo;
And then did
On Wed, Jul 27, 2011 at 2:29 PM, Robert Haas wrote:
> The reason the benefit is smaller is, I believe, because the previous
> numbers were generated with the lazy vxid locks patch applied, and
> these were generated against master. With the lock manager as a
> bottleneck, the sinval stuff doesn't
On Wed, Jul 27, 2011 at 1:58 PM, Noah Misch wrote:
>> > I think a benchmark is in order, something like 900 idle connections and 80
>> > connections running small transactions that create a few temporary tables.
>> > If
>> > that shows no statistically significant regression, then we're probably
On Wed, Jul 27, 2011 at 01:30:47PM -0400, Robert Haas wrote:
> On Wed, Jul 27, 2011 at 12:55 PM, Noah Misch wrote:
> > [wrong objection]
>
> Eh, how can this possibly happen? You have to hold msgNumLock to to
> set maxMsgNum and msgNumLock to read maxMsgNum. If that's not enough
> to guarantee
On Wed, Jul 27, 2011 at 12:55 PM, Noah Misch wrote:
> This approach would work if a spinlock release constrained the global stores
> timeline. It makes a weaker guarantee: all stores preceding the lock release
> in program order will precede it globally. Consequently, no processor will
> observe
On Tue, Jul 26, 2011 at 09:57:10PM -0400, Robert Haas wrote:
> On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch wrote:
> > No new ideas come to mind, here.
>
> OK, I have a new idea. :-)
>
> 1. Add a new flag to each procState called something like
> "timeToPayAttention".
> 2. Each call to SIGetDat
On Wed, Jul 27, 2011 at 12:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 26, 2011 at 9:57 PM, Robert Haas wrote:
>>> 1. Add a new flag to each procState called something like
>>> "timeToPayAttention".
>>> 2. Each call to SIGetDataEntries() iterates over all the ProcStates
>>> whos
Robert Haas wrote:
> There turned out to be a little bit of further subtlety to this,
> but it seems to work. Patch attached.
Stylistic question: Why is stateP->hasMessages set to false in one
place and FALSE and TRUE in others? It seems like it would be less
confusing to be consistent.
A
Robert Haas writes:
> On Tue, Jul 26, 2011 at 9:57 PM, Robert Haas wrote:
>> 1. Add a new flag to each procState called something like
>> "timeToPayAttention".
>> 2. Each call to SIGetDataEntries() iterates over all the ProcStates
>> whose index is < lastBackend and sets stateP->timeToPayAttenti
On Tue, Jul 26, 2011 at 9:57 PM, Robert Haas wrote:
> On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch wrote:
>> No new ideas come to mind, here.
>
> OK, I have a new idea. :-)
>
> 1. Add a new flag to each procState called something like
> "timeToPayAttention".
> 2. Each call to SIGetDataEntries()
On Tue, Jul 26, 2011 at 06:04:16PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote:
> >> Dirty cache line, maybe not, but what if the assembly code commands the
> >> CPU to load those variables into CPU registers before doing the
> >> compar
On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch wrote:
> No new ideas come to mind, here.
OK, I have a new idea. :-)
1. Add a new flag to each procState called something like "timeToPayAttention".
2. Each call to SIGetDataEntries() iterates over all the ProcStates
whose index is < lastBackend and s
On Tue, Jul 26, 2011 at 3:25 PM, Simon Riggs wrote:
> On Tue, Jul 26, 2011 at 8:11 PM, Robert Haas wrote:
>> It wouldn't, although it might be bad in the case where there are lots
>> of temp tables being created and dropped.
>
> Do temp tables cause relcache invalidations?
>
> That seems like som
On Tue, Jul 26, 2011 at 3:34 PM, Simon Riggs wrote:
> You might be right, but I think we have little knowledge of how some
> memory barrier code you haven't written yet effects performance on
> various architectures.
>
> A spinlock per backend would cache very nicely, now you mention it. So
> my m
Noah Misch writes:
> On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote:
>> Dirty cache line, maybe not, but what if the assembly code commands the
>> CPU to load those variables into CPU registers before doing the
>> comparison? If they're loaded with maxMsgNum coming in last (or at
>> lea
On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > That's the theoretical risk I wished to illustrate. Though this appears
> > possible on an abstract x86_64 system, I think it's unrealistic to suppose
> > that
> > a dirty cache line could persist *throughout* the
Noah Misch writes:
> On Tue, Jul 26, 2011 at 03:40:32PM -0400, Tom Lane wrote:
>> After some further reflection I believe this patch actually is pretty
>> safe, although Noah's explanation of why seems a bit confused.
> Here's the way it can fail:
> 1. Backend enters SIGetDataEntries() with main
On Tue, Jul 26, 2011 at 01:36:26PM -0400, Robert Haas wrote:
> On Mon, Jul 25, 2011 at 6:24 PM, Noah Misch wrote:
> > On Fri, Jul 22, 2011 at 03:54:03PM -0400, Robert Haas wrote:
> >> On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch wrote:
> >> > This is attractive, and I don't see any problems with i
On Tue, Jul 26, 2011 at 03:40:32PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
> >> I think I have a simpler idea, though:
> >> before acquiring any locks, just have SIGetDataEntries() do this:
> >>
> >> + if (stateP->nextMsgN
Noah Misch writes:
> On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
>> I think I have a simpler idea, though:
>> before acquiring any locks, just have SIGetDataEntries() do this:
>>
>> + if (stateP->nextMsgNum == segP->maxMsgNum && !stateP->resetState)
>> + retur
On Tue, Jul 26, 2011 at 8:11 PM, Robert Haas wrote:
* Can we partition the sinval lock, so we have multiple copies? That
increases the task for those who trigger an invalidation, but will
relieve the pressure for most readers.
>>>
>>> Not sure there's a way to meaningfully partitio
On Tue, Jul 26, 2011 at 8:11 PM, Robert Haas wrote:
> It wouldn't, although it might be bad in the case where there are lots
> of temp tables being created and dropped.
Do temp tables cause relcache invalidations?
That seems like something we'd want to change in itself.
--
Simon Riggs
Simon Riggs writes:
> On Tue, Jul 26, 2011 at 7:24 PM, Alvaro Herrera
> wrote:
>> Signals are already in use for special cases (queue is full), and I
>> think going through the kernel to achieve much more will lower
>> performance significantly.
> If there are no invalidations, there would be no
On Tue, Jul 26, 2011 at 2:56 PM, Simon Riggs wrote:
> On Tue, Jul 26, 2011 at 7:24 PM, Alvaro Herrera
> wrote:
>> Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
>>
>>> Let me ask a few questions to stimulate a different solution
>>>
>>> * Can we do this using an active tec
On Tue, Jul 26, 2011 at 7:24 PM, Alvaro Herrera
wrote:
> Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
>
>> Let me ask a few questions to stimulate a different solution
>>
>> * Can we do this using an active technique (e.g. signals) rather than
>> a passive one (reading a
Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
> Let me ask a few questions to stimulate a different solution
>
> * Can we do this using an active technique (e.g. signals) rather than
> a passive one (reading a counter?)
Signals are already in use for special cases (queue
On Tue, Jul 26, 2011 at 6:36 PM, Robert Haas wrote:
> Now, as you say, it seems really, really
> difficult to hit that in practice, but I don't see a way of getting
> rid of the theoretical possibility without either (1) a spinlock or
> (2) a fence. (Of course, on x86, the fence could be optimiz
Excerpts from Tom Lane's message of mar jul 26 13:43:08 -0400 2011:
> Uh, yes. I've lost count of the number of times I've seen people hit
> one-instruction-wide race condition windows, SIGSEGV crash based on
> accessing only one byte past the valid data structure, etc etc.
I think you need a be
Robert Haas writes:
> On further reflection, I don't see that this helps: it just moves the
> problem around. With resetState as a separate variable, nextMsgNum is
> never changed by anyone other than the owner, so we can never have a
> stale load. But if we overload nextMsgNum to also indicate
On Mon, Jul 25, 2011 at 6:24 PM, Noah Misch wrote:
> On Fri, Jul 22, 2011 at 03:54:03PM -0400, Robert Haas wrote:
>> On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch wrote:
>> > This is attractive, and I don't see any problems with it. (In theory, you
>> > could
>> > hit a case where the load of res
On Fri, Jul 22, 2011 at 03:54:03PM -0400, Robert Haas wrote:
> On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch wrote:
> > This is attractive, and I don't see any problems with it. (In theory, you
> > could
> > hit a case where the load of resetState gives an ancient "false" just as the
> > counters
On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch wrote:
> On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
>> I think I have a simpler idea, though:
>> before acquiring any locks, just have SIGetDataEntries() do this:
>>
>> + if (stateP->nextMsgNum == segP->maxMsgNum && !stateP->reset
On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
> I think I have a simpler idea, though:
> before acquiring any locks, just have SIGetDataEntries() do this:
>
> + if (stateP->nextMsgNum == segP->maxMsgNum && !stateP->resetState)
> + return 0;
>
> Patch (with comme
On Thu, Jul 21, 2011 at 9:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 21, 2011 at 6:43 PM, Noah Misch wrote:
>>> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
SIGetDataEntries() can pretty easily be made lock-free. The only real
changes that seem to be a
Robert Haas writes:
> On Thu, Jul 21, 2011 at 6:43 PM, Noah Misch wrote:
>> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
>>> SIGetDataEntries() can pretty easily be made lock-free. The only real
>>> changes that seem to be are needed are (1) to use a 64-bit counter, so
>>> you ne
On Thu, Jul 21, 2011 at 6:43 PM, Noah Misch wrote:
> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
>> Profiling this combination of patches reveals that there is still some
>> pretty ugly spinlock contention on sinval's msgNumLock. And it occurs
>> to me that on x86, we really don'
On Thu, Jul 21, 2011 at 6:44 PM, Dan Ports wrote:
> If you're suggesting that hardware memory barriers aren't going to be
> needed to implement lock-free code on x86, that isn't true. Because a
> read can be reordered with respect to a write to a different memory
> location, you can still have pro
On Thu, Jul 21, 2011 at 6:22 PM, Florian Pflug wrote:
> On Jul21, 2011, at 21:15 , Robert Haas wrote:
>> On Thu, Jul 21, 2011 at 2:50 PM, Tom Lane wrote:
>>> Robert Haas writes:
... On these machines, you need to issue an explicit memory barrier
instruction at each sequence point, or j
On Jul21, 2011, at 03:46 , Robert Haas wrote:
> Profiling this combination of patches reveals that there is still some
> pretty ugly spinlock contention on sinval's msgNumLock. And it occurs
> to me that on x86, we really don't need this lock ... or
> SInvalReadLock ... or a per-backend mutex. Th
On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
> Profiling this combination of patches reveals that there is still some
> pretty ugly spinlock contention on sinval's msgNumLock. And it occurs
> to me that on x86, we really don't need this lock ... or
> SInvalReadLock ... or a per-bac
On Thu, Jul 21, 2011 at 02:31:15PM -0400, Robert Haas wrote:
> 1. Machines with strong memory ordering. On this category of machines
> (which include x86), the CPU basically does not perform loads or
> stores out of order. On some of these machines, it is apparently
> possible for there to be som
On Jul21, 2011, at 21:15 , Robert Haas wrote:
> On Thu, Jul 21, 2011 at 2:50 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... On these machines, you need to issue an explicit memory barrier
>>> instruction at each sequence point, or just acquire and release a
>>> spinlock.
>>
>> Right, and the
On Thu, Jul 21, 2011 at 4:54 PM, Noah Misch wrote:
> On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
>> For the last week or so, in between various other tasks, I've been
>> trying to understand why performance drops off when you run pgbench -n
>> -S -c $CLIENTS -j $CLIENTS -T $A_FEW_
On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote:
> For the last week or so, in between various other tasks, I've been
> trying to understand why performance drops off when you run pgbench -n
> -S -c $CLIENTS -j $CLIENTS -T $A_FEW_MINUTES at very high client
> counts. The answer, in a w
On Thu, Jul 21, 2011 at 3:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think the real challenge is going to be testing. If anyone has a
>> machine with weak memory ordering they can give me access to, that
>> would be really helpful for flushing the bugs out of this stuff.
>
> There are mul
Robert Haas writes:
> I think the real challenge is going to be testing. If anyone has a
> machine with weak memory ordering they can give me access to, that
> would be really helpful for flushing the bugs out of this stuff.
There are multi-CPU PPCen in the buildfarm, or at least there were last
On Thu, Jul 21, 2011 at 8:25 PM, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 3:22 PM, Dave Page wrote:
>> On Thu, Jul 21, 2011 at 8:15 PM, Robert Haas wrote:
>>> I think the real challenge is going to be testing. If anyone has a
>>> machine with weak memory ordering they can give me access to,
On Thu, Jul 21, 2011 at 3:22 PM, Dave Page wrote:
> On Thu, Jul 21, 2011 at 8:15 PM, Robert Haas wrote:
>> I think the real challenge is going to be testing. If anyone has a
>> machine with weak memory ordering they can give me access to, that
>> would be really helpful for flushing the bugs out
On Thu, Jul 21, 2011 at 8:15 PM, Robert Haas wrote:
>
> I think the real challenge is going to be testing. If anyone has a
> machine with weak memory ordering they can give me access to, that
> would be really helpful for flushing the bugs out of this stuff.
> Getting it to work on x86 is not the
On Thu, Jul 21, 2011 at 2:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... On these machines, you need to issue an explicit memory barrier
>> instruction at each sequence point, or just acquire and release a
>> spinlock.
>
> Right, and the reason that a spinlock fixes it is that we have memory
Robert Haas writes:
> ... On these machines, you need to issue an explicit memory barrier
> instruction at each sequence point, or just acquire and release a
> spinlock.
Right, and the reason that a spinlock fixes it is that we have memory
barrier instructions built into the spinlock code sequenc
On Thu, Jul 21, 2011 at 12:16 PM, Kevin Grittner
wrote:
> Very impressive! Those numbers definitely justify some #ifdef code
> to provide alternatives for weak memory ordering machines versus
> others. With the number of CPUs climbing as it is, this is very
> important work!
Thanks. I'm not th
Robert Haas wrote:
> SIGetDataEntries(). I believe we need to bite the bullet and
> rewrite this using a lock-free algorithm, using memory barriers on
> processors with weak memory ordering.
> [32 processors; 80 clients]
> On unpatched master
> tps = 132518.586371 (including connections es
For the last week or so, in between various other tasks, I've been
trying to understand why performance drops off when you run pgbench -n
-S -c $CLIENTS -j $CLIENTS -T $A_FEW_MINUTES at very high client
counts. The answer, in a word, is SIGetDataEntries(). I believe we
need to bite the bullet and
56 matches
Mail list logo
